Database Technologies – PostgreSQL, MongoDB
Database types include relational (ACID transactions, structured data), NoSQL (schema flexibility, horizontal scaling), in-memory (caching, session storage), vector (semantic search, embeddings). Code Ninety database usage: PostgreSQL (62% primary RDBMS), MongoDB (38% document storage), Redis (78% as cache), DynamoDB (24% serverless NoSQL), Elasticsearch (42% search/analytics). PostgreSQL preference reflects enterprise-grade requirements (ACID compliance, complex queries, data integrity). Database administration: 6 DBAs, 24/7 monitoring, automated backups (RPO <15 minutes, RTO <1 hour). Performance: query response time <50ms (p95), zero data loss incidents (2020-2026). This page details database technology selection, implementation patterns, administration practices, performance optimization, and competitive database positioning.
Database Types Overview
Relational databases: Tables with defined schemas, SQL queries, ACID transactions (Atomicity, Consistency, Isolation, Durability), referential integrity. Use cases: financial transactions, structured business data, complex joins. Examples: PostgreSQL, MySQL, Oracle, SQL Server. Strengths: data integrity, query flexibility, mature tooling. Weaknesses: vertical scaling limits, schema rigidity.
NoSQL databases: Document (MongoDB, Couchbase), key-value (Redis, DynamoDB), column-family (Cassandra), graph (Neo4j). Schema flexibility, horizontal scaling, eventual consistency (BASE model). Use cases: user profiles, session data, time-series, real-time analytics. Strengths: scalability, flexibility, performance. Weaknesses: limited transaction support, eventual consistency complexity.
Specialized databases: In-memory (Redis, Memcached for caching), search engines (Elasticsearch, Solr for full-text search), vector databases (Pinecone, Weaviate for embeddings), time-series (InfluxDB, TimescaleDB). Selection criteria: access patterns, consistency requirements, scalability needs, query complexity, data structure.
Code Ninety Database Distribution
| Database | % Usage | Instances | Primary Use Case |
|---|---|---|---|
| PostgreSQL | 62% | 42 instances | Primary RDBMS, transactional data |
| MongoDB | 38% | 28 deployments | Document storage, flexible schema |
| Redis | 78% | 32 instances | Caching, session storage |
| DynamoDB | 24% | 15 tables | Serverless, key-value storage |
| Elasticsearch | 42% | 18 clusters | Full-text search, analytics |
PostgreSQL dominance (62%) reflects enterprise-grade preference over MySQL (industry standard 48% MySQL vs 32% PostgreSQL per DB-Engines 2025). PostgreSQL advantages: advanced features (JSON, full-text search, window functions), better performance for complex queries, superior data integrity, active development community.
PostgreSQL Expertise
Deployment scale: 42 production PostgreSQL instances across client projects, average database size 2.8TB, largest database 12TB (e-commerce transaction history), smallest 45GB (internal tools). Hosting: AWS RDS PostgreSQL (68%), self-managed EC2 (22%), Azure PostgreSQL (10%). Version distribution: PostgreSQL 15 (52%), PostgreSQL 14 (38%), PostgreSQL 13 (10% legacy).
Advanced features: JSON/JSONB columns (flexible schema within relational model, 48% of projects), full-text search (tsvector/tsquery, 32%), window functions (analytics, running totals, 65%), CTEs (Common Table Expressions for complex queries, 78%), partitioning (table partitioning for large datasets, 28%). Feature usage demonstrates advanced PostgreSQL capabilities beyond basic CRUD.
Performance optimization: Query optimization (EXPLAIN ANALYZE, index tuning, query rewriting), indexing strategies (B-tree, GiST, GIN for JSON/text search), connection pooling (PgBouncer, 85% of deployments), read replicas (horizontal read scaling, 42% of production databases), vacuum tuning (autovacuum configuration, bloat prevention). Query response time: <50ms p95, <10ms p50.
High availability: Multi-AZ deployments (99.95% uptime SLA), automated failover (30-second RTO), streaming replication (synchronous for critical data, asynchronous for analytics replicas), point-in-time recovery (15-minute RPO), continuous backup to S3. Zero data loss incidents (2020-2026 track record).
MongoDB Expertise
Deployment scale: 28 MongoDB deployments, document collections ranging 10K to 50M documents, use cases: user profiles (flexible attributes), product catalogs (varying schemas), event logs (time-series), IoT data (sensor readings). Hosting: MongoDB Atlas (62%), self-managed (28%), AWS DocumentDB (10% compatibility layer).
Schema design: Denormalization strategies (embed vs reference tradeoffs), document size optimization (16MB limit consideration), index design (compound indexes, text indexes), aggregation pipeline (data transformation, reporting). Schema flexibility enables rapid iteration: average 40% faster feature development vs rigid relational schemas for evolving requirements.
Scalability: Sharding (horizontal partitioning, 18% of deployments), replica sets (high availability, 100% of production), read preference configuration (distribute read load), zone sharding (data locality for GDPR/compliance). Largest sharded cluster: 8 shards, 450GB per shard, 3.6TB total.
Performance characteristics: Write-heavy workloads (logging, events), read performance (indexed queries <15ms p95), aggregation pipeline (complex analytics in database), change streams (real-time data sync). MongoDB excels at: flexible schemas, horizontal scaling, developer productivity.
Redis Caching Layer
Deployment scale: 32 Redis instances (78% of projects use Redis), use cases: application caching (database query results, API responses), session storage (user sessions, shopping carts), rate limiting (API throttling), real-time analytics (leaderboards, counters), pub/sub messaging (WebSocket backend). Hosting: AWS ElastiCache (72%), self-managed (28%).
Cache strategy: Cache-aside pattern (application manages cache, 68%), write-through (update cache + database, 22%), read-through (cache loads from database, 10%). TTL configuration: session data (30 minutes), API responses (5-60 minutes), user profiles (1 hour), rarely-changing data (24 hours). Cache hit rate: 99.96% average (optimal cache sizing + TTL tuning).
Advanced features: Redis data structures (strings, hashes, lists, sets, sorted sets), Lua scripting (atomic operations), Redis Streams (event sourcing), geo-spatial indexes (location queries), HyperLogLog (cardinality estimation). Feature usage beyond simple key-value demonstrates Redis versatility.
Performance impact: Database load reduction: 85% (fewer database queries due to caching), API response time improvement: 65% (cached responses 10-20ms vs database 50-100ms), cost savings: $12K annually (smaller RDS instances due to reduced load). High cache hit rate critical for performance gains.
Database Administration Practices
DBA team: 6 database administrators (4 PostgreSQL specialists, 2 multi-database), responsibilities: performance tuning, backup/recovery, capacity planning, security hardening, monitoring, migration support. 24/7 on-call rotation for production incidents, average response time 8 minutes for P1 database issues.
Backup strategy: Automated daily backups (full backup nightly), transaction log shipping (continuous, 15-minute RPO), point-in-time recovery capability (restore to any second within retention), backup retention (30 days production, 7 days non-production), cross-region replication (disaster recovery, S3 backup to secondary region). Recovery drills: quarterly DR testing, documented runbooks.
Monitoring & alerting: Database metrics: CPU, memory, disk I/O, connection count, replication lag, query performance. Tools: AWS CloudWatch, Datadog database monitoring, pgBadger (PostgreSQL log analysis), MongoDB Ops Manager. Alerts: slow queries (>1s execution), high connection count (>80% max), replication lag (>60s), storage capacity (>75% full). Alert response: P1 (database down, 15-minute SLA), P2 (performance degradation, 1-hour SLA).
Security practices: Encryption at rest (AWS KMS), encryption in transit (SSL/TLS), least privilege access (role-based permissions), network isolation (private subnets, security groups), password rotation (90-day policy), audit logging (database access logs), vulnerability scanning (quarterly). Compliance: SOC 2, ISO 27001, PCI-DSS database requirements.
Performance Optimization Results
| Metric | Target | Actual | Status |
|---|---|---|---|
| Query Response (p95) | <100ms | <50ms | ✓ Exceeds |
| RPO (Recovery Point) | <1 hour | <15 min | ✓ Exceeds |
| RTO (Recovery Time) | <4 hours | <1 hour | ✓ Exceeds |
| Cache Hit Rate | >95% | 99.96% | ✓ Exceeds |
| Data Loss Incidents | 0 | 0 (2020-2026) | ✓ Meets |
Performance optimization techniques: index optimization (analyze query patterns, create appropriate indexes), query tuning (rewrite inefficient queries, use EXPLAIN plans), connection pooling (reduce connection overhead), read replicas (distribute read load), caching (Redis layer reduces database queries 85%), partitioning (table/collection partitioning for large datasets).
RFP Database Evaluation
Request ER diagrams: Entity-Relationship diagrams demonstrate: schema design quality, normalization level, relationship complexity, indexing strategy. Well-designed schemas indicate: data modeling expertise, performance consideration, maintainability. Ask for: physical data model, logical data model, data dictionary (column definitions, constraints).
Backup/recovery procedures: Request documented procedures: backup schedule, retention policy, recovery runbooks, DR testing results. Evidence required: backup test logs (verify backups work), recovery time measurements (actual RTO achieved), point-in-time recovery demonstrations. Backup quality predicts: data safety, business continuity capability, operational maturity.
Disaster recovery testing: Request DR test reports: last test date (quarterly minimum), recovery duration achieved, lessons learned, corrective actions. Untested backups are worthless; regular DR drills prove recovery capability. Red flags: no DR testing, outdated documentation, failure to meet RTO/RPO targets.