Every ORM benchmark I see online tests the same trivial query: SELECT * FROM users WHERE id = 1;

This doesn't benchmark an ORM. It benchmarks Linux loopback TCP socket round-trip time.

In production, ORMs don't fall over on primary-key lookups. They buckle when:

1. Deserializing 10,000 wide rows into typed structs under memory pressure.

2. Materializing 4-level deep entity graphs without Cartesian explosions or N+1 floods.

3. Compiling recursive CTEs, multi-frame window functions (ROWS BETWEEN 4 PRECEDING), or pgvector cosine similarity.

4. Squeezing 100 concurrent workers competing for row locks (SELECT ... FOR UPDATE) through a constrained connection pool.

5. Emitting 300 lines of incomprehensible internal template/typeclass garbage when a database column type changes.

To see how modern ORMs actually behave under load, I built a standardized, reproducible benchmark suite testing 25 ORMs across 9 programming languages (Go, Rust, C#, Java, Elixir, TypeScript, Python, Ruby, Haskell) against the official Postgres Air database (2024 edition, 78,232,673 real-world flight records on PostgreSQL 17 with pgvector).

Every single ORM was held to the exact same invariants: a strict 20-connection pool, zero raw string interpolation (native typed query builders only), and typed entity deserialization into domain records.

The Executive Leaderboard

The 5 Biggest Surprises

1. The Zero-Reflection Hydration Tier (> 1.2M rows/sec): sqlc (1.52M rows/s), EF Core 8 (1.39M rows/s), diesel (1.37M rows/s), and Dapper (1.28M rows/s) operate in a different galaxy compared to reflection-heavy ORMs. Direct struct memory mapping and compiled pointer assignments destroy runtime reflection when reading wide tables.

2. The BEAM Actor Model Destroyed Connection Contention: Under $C=100$ concurrent load on a 20-connection pool, most runtimes bottlenecked on thread pools or single event loops. Elixir’s ecto handled pool checkout through isolated BEAM process mailboxes with near-zero queue latency, sustaining 29,412 requests/second.

3. Node.js / V8 Event Loop Saturation: TypeScript ORMs (drizzle, prisma, typeorm) performed well on single queries, but hit an unmistakable wall at $C=50..100$. Because V8 serializes and constructs thousands of JavaScript objects on a single thread, CPU time saturated the event loop, driving $p_{99}$ tail latencies beyond 500 ms and capping RPS around 225–264 ops/s.

4. Haskell’s Memory Anomaly: Haskell’s hasql clocked the lowest resident memory footprint of the entire 25-ORM field at just 13.03 MB Peak Heap RSS, utilizing zero-copy PostgreSQL binary codecs.

5. The Deliberate Mistake Suite (Compiler UX): We injected 10 deliberate compiler mistakes (type mismatches, dangling joins, nullability violations, scope leakage). While tools like sqlc, squeal, hasql, and ent caught errors in 6–10 lines of clean output, complex typeclass/macro builders (rel8, drizzle) sometimes spewed 60–80 lines of internal framework plumbing.

Reproduce It / Add Your Favorite ORM

The benchmark repo contains all calculations, runner scripts, Docker setup, and the 25 JSON scorecards:

👉 GitHub Repository: https://github.com/tusharad/orm-benchmark

If you want to add an ORM (e.g. Kysely, Slonik, Bun, Peewee, SQLDelight), check out templates/generic/HARNESS_CONTRACT.md and submit a PR!

I'd love to hear your thoughts, critique of the methodology, or experiences running these tools in high-throughput production.

A design question I think is easy to get wrong: what should your health check do when a dependency is unavailable?

Here’s a hypothetical timeline (constructed, not from a real incident):

1. The database becomes unreachable for a few minutes.

2. The service has a single health endpoint that checks the database connection.

3. The orchestrator uses that same endpoint to decide whether to restart the container.

4. Every instance fails the check, so every instance gets restarted.

5. The database comes back, but now all instances are cold: empty caches, new connection pools, all reconnecting at once.

Restarting didn’t fix anything, because the problem was never inside the process. It added load at the worst moment.

The distinction that avoids this (as I understand it):

• Liveness: “is this process stuck or broken in a way a restart would fix?” It should check only the process itself, for example that it can respond at all. It generally shouldn’t depend on external services.

• Readiness: “should this instance receive traffic right now?” This is where a dependency check can make sense. If the database is down, the instance reports “not ready” and the load balancer stops sending it requests, without killing it.

Many platforms (Kubernetes is the one I know best) separate these two probes, but the names and exact behavior vary, so check your platform’s docs. If you don’t have an orchestrator, the same question applies to your load balancer’s health check.

Things worth deciding on purpose:

• Should “not ready” because of the database mean returning errors, or serving degraded responses (cached data, read-only mode)? That’s a product decision as much as a technical one.

• A readiness check that hits the database on every probe adds load and can itself time out. Some teams cache the result for a few seconds.

• Startup is its own case. A slow-starting service may need a separate startup check so that liveness doesn’t kill it before it finishes initializing.

Limits: this is one pattern, not a rule for every system. Tiny services behind a simple load balancer may not need any of it, and a dependency that’s truly required for every request changes the calculus.

How do you split these in your services? And what do you do for a dependency that’s down: fail readiness, degrade, or something else?

Hi everyone,

I spent a year as a backend GET (Core Java, Spring Boot, SQL) at a government org, but didn't get the PPO due to internal politics.

I’m back on the job hunt and feeling overwhelmed by what to study to stand out. I'm currently diving into Spring AOP and Hibernate internals, but I need a reality check.

To senior devs:

1. Java Depth: How much is expected for 1 YOE? Is Core Java + Spring Boot enough, or do I need to master things like Kafka, multithreading, and microservices to get hired today?

2. AI Skills: Every job description mentions AI. For a backend developer, where should I start? Are simple OpenAI/Gemini API integration projects enough?

Looking for harsh truths and realistic advises. Thanks!

Hey everyone!

I'm trying to understand how companies typically manage staging and production environments, and what the industry best practices are.

I've mostly worked on smaller projects, but I'm now working on a project where I need to introduce a proper staging environment alongside an existing production environment. I want to make sure I'm approaching this correctly rather than creating unnecessary complexity.

A few questions I have:

1. Repository structure: Do companies typically keep staging and production code in the same Git repository, using separate branches (e.g., main for production and staging for staging)?

2. Separate repositories: Is it ever common to have two completely separate repositories, one for staging and another for production? If so, how are changes migrated between them?

3. Deployment: Do both environments usually have their own deployments, servers, and domains/subdomains (e.g., staging.example.com and example.com)?

4. CI/CD: How is the deployment process typically handled? For example, would pushing to a staging branch automatically deploy to staging, while merging into main triggers a production deployment?

5. Promoting changes: Once a feature has been tested and approved in staging, what's the standard way to promote those exact changes to production without introducing unexpected differences?

Or am I misunderstanding the concept entirely, and is there a completely different approach that most companies follow?

I'm particularly interested in how this is handled in real-world projects, not just theoretically.

I'd appreciate any explanations, examples of actual workflows, or resources you could recommend.

Thanks in advance!

I have been contributing to an open source Redis-compatible database project. I am trying to understand the real challenges people face when running Redis in production.

What i have seen so far some of the biggest challenges seem ro be memory usage, latency spikes under heavy load and recovery after failure.

I’d love to hear about your experience. What’s been the hardest problem you have dealt with?

As the title says, I wrote a personal replacement for postman to manage both my one off api testing as well as my test suites run after a deploy to walk through a client journey (with negative pass assertions) to make sure things work as expected. It’s totally free and currently on TestFlight. it’s mostly tuned for my own workflow but sharing here in case anyone else finds it useful or had feedback

Personally, I'm really enjoying Hono. Its automatic endpoint inference is a big win. I previously enjoyed using Fastify with Zod Provider for OpenAPI schema generation, but Hono cuts that extra step and makes the workflow feel much smoother.

Curious what everyone else is using!

Hey everyone,

I'm building Thunder, a high-performance key-value database designed for workloads where latency, throughput, and efficient resource utilization matter.

With AI applications, we're seeing increasing amounts of data being generated, stored, and retrieved. I wanted to explore whether we could build a database from the ground up that handles these workloads more efficiently, rather than simply relying on larger amounts of RAM.

The core idea is simple: use RAM intelligently, not excessively.

Thunder is being built in Rust with a few architectural decisions:

• Shard-per-core architecture: Each core owns its data, minimizing contention and synchronization overhead.

• Asynchronous I/O: Uses io_uring on Linux to take advantage of modern NVMe storage.

• Minimal RAM overhead: Keep essential metadata and indexes in memory while streaming data from storage through reusable buffers.

• Zero-copy wherever possible: Reduce unnecessary memory copies and allocations.

• Custom storage engine: Designed around efficient allocation, fragmentation management, and predictable performance.

• High concurrency: Handle large numbers of concurrent operations without relying on traditional locking across the entire database.

The long-term goal is to support both small, latency-sensitive operations and large data workloads without requiring enormous amounts of memory.

It's still under development, and I'm experimenting with different approaches to storage, indexing, caching, and I/O scheduling.

I'd love to hear from people building AI infrastructure or working with large-scale key-value stores.

What are the biggest bottlenecks you're facing with your current databases? Is it memory consumption, read latency, write throughput, storage costs, or something else?

Also, what would you expect from a new key-value database built specifically with AI workloads in mind?

Docker link: https://hub.docker.com/r/sbansal793/thunderstrike

We are revamping our tooling and processes for API development and testing in my org and want to understand which teams typically use and own these tools (Devs, QAs or both).

I’ve seen teams handle this very differently. In some, only backend devs use API clients like Postman, Bruno while in others its a shared responsbility with QAs - curious what’s more common.

Would love to hear in comments how clear the ownership is, or how you make it work.

I've been building a self-hosted web scraping API that makes automation easy.

Relinos can handle JavaScript and challenging websites, performs browser interactions, and executes multiple scraping requests concurrently.

Key features:

• Browser automation: Navigate, click, type, scroll, and interact with websites.

• Concurrent execution: Run multiple browser sessions simultaneously.

• Structured extraction: Extractions are very easy to define here an extraction for google for example:

{
    "query": { "$xpath": "//*[@id='ti6dpd']" },
    "result_count": {
      "$xpath": "//div[@class='XhWQv qd6zO ApHyTb']",
      "$extract": "\\D*(\\d[,\\d]*) .*"
    },
    "ai": {
      "$xpath": "//*[@class='mZJni Dn7Fzd']", "$format": "md"
    },
    "results": {
      "$xpath": "//div[contains(@class, 'MjjYud')]",
      "title": { "$xpath": ".//h3[contains(@class, 'LC20lb MBeuO DKV0Md')]" },
      "url": { "$xpath": ".//a[contains(@class, 'zReHs')]/@href" },
      "site": { "$xpath": ".//span[contains(@class, 'VuuXrf')]" },
      "snippet": { "$xpath": ".//div[contains(@data-snf, 'nke7rc')]" },
      "$list": true
    },
    "related_searches": {
      "$xpath": "//*[@class='qR29te']", "$list": true
    }
}

• Reusable routines: create, import or export. I wanted to make this super easy so people can share their interactions and extractions.

• Language-independent: Access everything through a simple HTTP API.

• Debug Mode: Find issues with rendered site interactions visually and fix them fast

• Self-hosted: Run it locally without a commercial scraping service.

• Transferable Sessions: Cookies and localStorage.

The project is still in early development, and feedback or contributions are welcome.

GitHub: https://github.com/realsirjoe/relinos

Hey guys, I've been looking to create a service to recover money from failed payments that happen on razorpay and stripe. I know this isn't necessarily a backend question, but many companies write their own code using the provider SDKs to handle payments.

Now I know that razorpay and stripe already have their own dunning engines, but for people who work with both the providers it must be hard to manage both of them.

Here are some information that I would love to know from you guys if possible.

• How do you handle failed subscription renewals?

• What share of your renewals fail each month, and what happens after?

• Do you rely on the providers retry / emails, chase customers manually or just lose them?

I'm researching this before I build anything, so even if you could just tell me that "It isn't a problem for us", it would be helpful.

I've been thinking a lot about backend architecture lately, especially when starting a new project.

One decision I keep coming back to is choosing a modular monolith over microservices.

My current approach is to start with NestJS, PostgreSQL, and Prisma, using a modular monolith architecture.

Here's why:

1. Simpler infrastructure

I don't want to introduce the operational complexity of multiple services before there's a real need for them.

2. Clear module boundaries

I still want the codebase to be modular, with each module owning its responsibilities and business logic.

3. Easier development and debugging

Keeping things in one deployable application makes local development, debugging, and transactions simpler.

4. Room to evolve

If a particular module eventually needs independent scaling or deployment, I want the architecture to make that transition possible.

But I also recognize that a modular monolith can become a distributed monolith in disguise if module boundaries aren't properly enforced.

I'm curious about how other backend engineers approach this.

A few questions:

• At what point do you consider microservices a necessity rather than an architectural preference?

• How do you enforce boundaries between modules in a NestJS application?

• Have you experienced a modular monolith becoming difficult to maintain as the project grew?

I'd be interested in hearing about real-world experiences, including mistakes you've made along the way.

I built RockxyBit, a native Postman alternative for Mac. It is a local API workbench: I write a request, send it, and inspect the response in the same window.

The 0.1.0 release lets me organize requests in collections and environments, inspect status, headers, cookies, timing, and the body, and import from cURL, HAR, Postman, OpenAPI, and SoapUI. GraphQL request bodies are in this release. Work stays on my Mac, and secrets I save through Keychain stay in the macOS Keychain.

Community is free. Pro adds comparison, a runner, and mock-server tools. It requires macOS 26.2 or later.

I would like feedback from people who test APIs every day, especially on import and the inspect workflow.

Website: https://rockxy.io/rockxybit
Bug report and feature request: https://github.com/RockxyApp/RockxyBit

Hey r/Backend!

I’ve been working on loadbear, a small, dependency-light HTTP reverse proxy and load balancer written in Go, and I'd love to get some architectural feedback from backend engineers here.

Why I built it: Most reverse proxies fall into two extremes: massive production tools (Nginx, Envoy, HAProxy) with heavy configuration overhead, or overly simplistic toy proxies that skip real-world fault tolerance. I wanted a self-contained binary configured via a single YAML file that stays readable and easy to inspect while still implementing proper backend resilience patterns.

Request Pipeline & Architecture: Incoming traffic flows through a sequential middleware/handler pipeline before hitting Go’s httputil.ReverseProxy:ProxyListener -> Per-IP Rate Limiter -> Balancer -> Circuit Breaker -> Upstream Backend

Core Backend Features:

• Load Balancing Algorithms: Implements round_robin, smooth_weighted_round_robin (Nginx-style smooth distribution), least_connections (tracking active in-flight requests), and ip_hash.

• Active & Passive Health Tracking: Combines periodic /health probing with passive failure detection—upstream proxy errors immediately mark a backend unhealthy without waiting for the next probe interval.

• Per-Backend Circuit Breakers: Tracks consecutive failures and transitions backends through Closed -> Open -> Half-Open states with configurable cooldown timers.

• Context-Aware Retries: Automatically retries idempotent requests (GET, HEAD, OPTIONS) on upstream failures with configurable backoff, respecting client request context cancellations.

• Per-Client-IP Rate Limiting: Token-bucket limiter with a background worker that periodically evicts stale client buckets to prevent unbounded memory growth.

• Observability & Ops: Separate admin listener (:9090) exposing a live JSON /status endpoint (active connections, circuit states, failure counts) and a hand-written Prometheus /metrics endpoint, alongside structured JSON access logs with request IDs and graceful shutdown (SIGINT/SIGTERM).

Local Failover Demo: It ships with a fakebackend CLI and a docker-compose.yml setup so you can spin up three nodes, kill one mid-traffic, and watch passive health checks, retries, and circuit breakers kick in immediately. Everything is tested with Go's race detector (go test -race ./...).

Current Limitations / Next Steps:

• Hop-by-hop header stripping currently drops Upgrade, so WebSocket support isn't implemented yet.

• SIGHUP config hot-reloading and formal load/throughput benchmarks are next on the list.

If anyone wants to review the concurrency handling, circuit breaker state machine, or general Go structure, any critique or PRs are welcome!

I have 2 years of experience in the startup and they did not provide pf for entire organisation now I am about shift the company..getting calls from mnc but when I said not have pf it's over...never think pf gonne be this much problems and due to this always getting demotivate for preparing interviews also

Someone can you share your thoughts

Are you working in a startup company that chose Java 25 as a backend language?

What is your impression regarding developer experience, performance and easiness build things fast?

A year ago I asked on r/OpenAPI for an offline, Stoplight-style API designer. Some of my work is on networks with no internet access, so hosted tools are out, and I didn't want to hand-write thousands of lines of YAML either. Nothing fit, so I built OpenAPI Studio, a native Windows desktop app.

What it does for the API owner:

• Visual design without losing the YAML. You edit operations, parameters, responses and schemas in forms and tables, and the YAML stays in sync in a code editor alongside. Every view edits the same document, so they never disagree.

• Specs split across files. It resolves ./schemas/order.yaml#/Order-style $refs across files. Go to definition works across files, and renaming a component rewrites every $ref that points to it.

• Schema modelling. A canvas like a database diagram, with $ref, allOf, oneOf and anyOf relationships drawn between schemas.

• Linting. 49 rules covering compliance, naming, documentation and security (for example, a secured endpoint with no 401 response), with one-click fixes and Strict, Recommended or Minimal rule sets.

• Breaking-change diff. Compare against the last saved version or any other file. Changes are classified as breaking, warning or compatible, with a semver suggestion.

• Contract testing. A mock server for the people using your API, and a request playground that checks real responses against the spec.

• Large specs. Tested on a spec with 59 paths, 115 operations and 73 schemas.

Everything runs locally: no account, no cloud, no telemetry. It supports OpenAPI 3.0 and 3.1.

Looking for testers, and honest opinions. It isn't publicly available yet, and it's Windows-only for now. I built it for my own work, and before I put more time in, I'd like to know whether it's useful to anyone else:

• Do you design the contract first, or generate it from code? If you generate it, would a tool like this change that?

• What do you use today to edit, lint and diff specs? For example Spectral, oasdiff, Redocly, or VS Code with plugins.

• Would Windows-only stop you?

If you'd like to test it, especially on large or multi-file real-world specs, comment or DM me.

With vibe coding blowing up lately, Java/Spring Boot feels like bringing a tank to a knife fight—way too heavy for how fast people are building things now.

Thinking about making the jump to Go or TypeScript. Has anyone else with a heavy enterprise Java background made this switch recently? Was it worth it, or is Java still where the actual money is?