Ten years ago, the "database-per-microservice" / polyglot persistence model was the right way to build. But today, the bottleneck isn't the database engine > it's the glue. What is the "ETL Tax"?
The ETL (Extract, Transform, Load) Tax is the hidden, compounding cost of moving data between specialized databases in a microservice/polyglot architecture. When your data is fractured across Postgres, Redis, Pinecone, and Neo4j, you don't just pay for the databases you pay a massive "tax" to keep them synchronized.
It impacts engineering teams in three fatal ways:
Engineering Time: Developers stop building product features and instead become "plumbers," writing brittle sync scripts, Debezium connectors, and Kafka pipelines.
Data Consistency & Staleness: Dealing with dual-write bugs, race conditions, and out-of-sync data (e.g., a user deletes their account in Postgres, but their embeddings still live in Pinecone).
Network Latency: You cannot do complex, real-time AI queries (like traversing a Graph and doing a Vector search) if the engines have to communicate over a network boundary.
One database for everything your app needs. Store user data, cache sessions, build AI search, and map relationships: all in one place. Instead of duct-taping Postgres, Redis, a Vector DB, and a Graph DB together, NodeDB gives you all of it in a single system.
I ve been playing around with RDX (Reactive Document eXpressions) recently and wanted to see what the community thinks about it.
For context: MDX is amazing, but because it allows arbitrary JavaScript execution, it s a massive security risk if you want to allow untrusted users to write content. RDX takes a different approach: it uses the same familiar JSX-style syntax (<Notice type="warning">), but it parses into a strict, safe AST with zero code execution.
Two things really stood out to me about this approach:
