Database Partitioning
Also known as: Sharding · Table partitioning
Partitioning splits a logical table into physical pieces along a chosen key — date, tenant, currency, region. Queries that filter on the partition key only touch the relevant slice; writes spread across slices instead of contending on one. PostgreSQL native partitioning (pg_partman for management) is TantraDev's default move when a single table exceeds a few hundred million rows or query latency starts climbing with table size.
Concepts that travel with this one.
Architecture rarely lives in isolation — these are the terms that come up in the same conversation.
PostgreSQL
PostgreSQL is an open-source relational database with strong ACID guarantees, MVCC concurrency, and rich extension surface (PostGIS, pg_partman, logical replication). It is the default datastore on every TantraDev engagement where the workload is transactional, the data has relationships, and the team needs the option to scale via partitioning and read replicas before reaching for a specialised store.
Horizontal Scaling
Horizontal scaling (scaling out) adds more identical instances behind a load balancer rather than making one instance bigger (vertical scaling). The constraint is whether the workload can be partitioned cleanly — shared mutable state, ordering requirements, or session affinity all push back. TantraDev's first move on a saturated single-server monolith is to find the partition key, not to upsize the box.
Building a system where Database Partitioning is the load-bearing decision?
30 minutes on the phone, one page in your inbox — what to build, what to skip, what it will cost. You keep the audit even if we are not the right fit.