The Database Question Is Obsolete in the AI Era
The question “Which database should I use?” belongs to a past era. In the age of AI, the real leverage comes from the execution layer — the APIs, auth, observability, and automation that sit above the engine. The database is no longer where velocity lives.
Tinkering with Time, Tech, and Culture #18
The classic developer question — Which database should I use? — is becoming obsolete.
In the AI era, database choice is rarely the starting line. For most modern apps, the database is a detail that follows the execution layer — the set of services and APIs that sits between application code and the engine itself.
This shift doesn’t mean the engine is irrelevant, but it does mean the execution layer is where velocity, security, and leverage now live.
What Is the Execution Layer?
It’s the layer that defines how developers interact with data. It’s where features like auth, APIs, automation, observability, and guardrails live.
When composable, secure-by-default, and high-leverage, the execution layer is what actually accelerates product cycles.
Execution-Layer-First vs Database-First
| Approach | Best for |
|---|---|
| Execution-layer-first | SaaS, prototypes, AI-first workloads |
| Database-first | Regulated infra, ultra-low-latency systems, BI |
In other words: you only lead with a database when forced by hard constraints — embedded/offline apps, sub-second analytics at massive scale, or compliance-driven locality.
In most cases, the differentiator is the layer above the engine.
What to Optimize in an AI-First Execution Layer
- Schema → API automation: auto-generated REST/GraphQL/TypeScript SDKs
- Auth + RLS by default: least-privilege access out of the box
- Vectors as a first-class citizen: embeddings, ANN indexes, hybrid search
- Events & functions: queues, crons, workers, retries, tracing
- Branching/preview environments: PR snapshots, rollbacks
- Observability: query traces, request-linked metrics
- Escape hatches: psql access, extensions, export/restore paths
Practical Picks by Workload
- General apps → Postgres-based execution layer (Supabase, Hasura+Neon, Railway, Fly). Add
pgvector; bolt on ClickHouse if analytics explode. - LLM/RAG workloads → Same stack +
pgvector/HNSW. For large corpora, offload to Milvus/FAISS or ClickHouse for metadata and logs. - Embedded/edge/offline → SQLite (Turso, D1) with central Postgres sync. DuckDB for local analytics.
- Firehose/time-series → OLTP in Postgres; OLAP in ClickHouse.
When the Engine Still Leads
- On-device or air-gapped persistence → SQLite
- Sub-second scans over billions of rows → ClickHouse
- In-process analytics, zero ops → DuckDB
- Multi-region writes or compliance locality → Distributed SQL
Anti-Lock-In Checklist
Before you adopt an execution layer, ask:
- Can I export in open formats (SQL, Parquet, S3)?
- Do I control IAM/keys, and can I self-host equivalents?
- Are migrations plain SQL and reproducible?
- Are vectors portable (not locked into proprietary formats)?
- Do I get typed SDKs from schema with ejection paths?
TL;DR
Pick the execution layer that maximizes velocity and guardrails — most often Postgres-based. Let the database default from there. Lead with a different engine only when your workload mandates it.
Supabase is a prime example: developers adopt the execution layer, and Postgres just comes with it.