Database Choices That Actually Matter for Nigerian Business Applications

The database technology conversation in software engineering is crowded with strong opinions built on use cases that do not apply to most business applications. MongoDB is not the right tool for every modern application. PostgreSQL is not the right tool for every structured dataset. Cassandra is almost certainly not the right tool for a ₦400M annual revenue distribution company's inventory system.

Nigerian business software operates in a specific context: multi-user business logic with financial implications, connectivity patterns that range from excellent fibre in Lagos Island offices to marginal 3G in northern distribution branches, regulatory requirements that increasingly specify where data must reside, and infrastructure economics that are different from the US market where most database tooling was designed.

The practical database questions for Nigerian business software are narrower than the general database debate and more consequential for project outcomes.

The Default Case: Relational Databases

The overwhelming majority of Nigerian business applications belong in a relational database. The reasons are structural:

Business data is relational. A customer has orders. An order has line items. A line item has a product. A product has a supplier. These relationships exist in the business and are best represented in a data model that enforces them.
Financial data requires ACID transactions. ACID — Atomicity, Consistency, Isolation, Durability — means that when a payment is recorded, the debit and credit happen together or not at all. When stock is decremented for an order, the inventory transaction and the order record update together. "Eventually consistent" databases — which relax these guarantees in favour of scale — are inappropriate for most financial and inventory applications.
SQL is universal and portable. Every developer understands SQL. Third-party tools (reporting, ETL, analytics) connect to PostgreSQL or MySQL natively. Future developers on your codebase can read and write SQL queries on their first day. The cognitive overhead of proprietary query languages is a long-term maintenance cost.

PostgreSQL vs MySQL: Both are production-grade. PostgreSQL has better support for complex queries, full-text search, JSON storage, range types, and advanced indexing — capabilities that matter for business applications with reporting requirements. MySQL (particularly in the InnoDB engine variant) is faster at simple read-heavy workloads and has wider hosting support at the low end of the pricing spectrum. For a new Nigerian business application in 2026, PostgreSQL is the default choice unless there is a specific reason to choose MySQL.

Infrastructure Options and Latency

Where your database runs affects every user interaction. A database in a US East data centre adds 150–250ms of round-trip latency to every query for a Lagos user. For a web application with 10–20 queries per page load, this is 1.5–5 seconds of additional latency before any application code runs.

AWS af-south-1 (Cape Town): The nearest major cloud region to Nigeria. Network latency from Lagos is typically 60–100ms. Not ideal — Cape Town to Lagos is still a significant distance — but materially better than US East or EU West. AWS RDS PostgreSQL and Amazon Aurora PostgreSQL run in af-south-1.

Google Cloud africa-south1 (Johannesburg): Similar distance to Cape Town. Cloud SQL for PostgreSQL available.

Neon (serverless PostgreSQL): Neon is a serverless PostgreSQL provider with data in AWS regions. Closest for Nigeria is eu-west-1 (Ireland) — approximately 100–130ms from Lagos — or us-east-1 (Virginia) — approximately 200ms. Neon is excellent for development and small-to-medium applications because of its branching capability (create a database branch for development like a Git branch), scale-to-zero billing, and generous free tier. Latency is acceptable for most administrative back-office applications where response time expectations are lower.

Render.com: Deploys in popular US/EU regions. Lowest latency Nigerian option is Frankfurt (~120ms from Lagos). Good developer experience, managed PostgreSQL with daily backups.

Railway: Similar to Render. Managed PostgreSQL, US and EU options. Reasonable for applications where sub-100ms database latency is not required.

Cloudflare D1: SQLite-based relational database that runs at Cloudflare's edge — including in a West Africa Cloudflare PoP. Sub-50ms latency from Lagos. The constraint: D1 is not yet suitable for write-heavy applications (it is eventually consistent for writes to global replicas, and the primary is in the US). Excellent for read-heavy edge use cases (content, product catalogues, lookup tables). Not appropriate for financial transaction databases.

On-premises or co-located: For applications with strict data residency requirements, a database server in a Nigerian data centre (MainOne, SCM Group, Rack Centre) eliminates cross-border latency and satisfies regulatory requirements. The operational overhead is higher: backup management, hardware failure response, and security maintenance are in-house responsibilities. For enterprise applications where a Lagos-based legal entity holds sensitive personal or financial data, co-location is often the right answer.

When to Use a Document Database

Document databases (MongoDB, Firebase Firestore, Supabase with JSONB) are appropriate for specific patterns:

Highly variable schema data: A product catalogue where different product types have fundamentally different attribute sets — electronics with technical specifications, clothing with size and colour variants, food products with nutritional information — is awkward in a rigid relational schema. A document store handles variable structure naturally.

Hierarchical data without cross-document queries: Content management systems where each document is independent, log and event data where each entry is self-contained, configuration stores where settings vary by context.

Rapid prototyping where schema will change frequently: A document database allows schema-free iteration during early product development. The risk: data quality problems that are caught early by relational constraints become difficult-to-detect inconsistencies in production.

What document databases are not for: Anything with complex relationships between entities. Anything where financial transactions require ACID guarantees. Anything where ad-hoc reporting and analytics queries traverse multiple entities. These use cases struggle with document storage and produce workarounds that are worse than a relational schema would have been.

A common pattern we see in Nigerian enterprise projects: a team selects MongoDB because it is familiar, then discovers eighteen months later that their financial reporting queries — which join across customer, transaction, and product data — would have been trivially fast in PostgreSQL but require complex aggregation pipelines in MongoDB. The database choice made at week one shapes every query written for years. Reversing it is not impossible, but it is expensive enough that most teams live with the workarounds instead.

Firebase / Firestore specifically: Popular for mobile backends and real-time synchronisation use cases. The serverless pricing model can produce surprising bills at scale (billed per document read — 100,000 document reads per day is neither unusual nor cheap). For Nigerian applications with cost sensitivity, the per-operation pricing model of Firestore deserves careful modelling before commitment.

Analytical Databases and Reporting

The operational database that runs your business — recording transactions, tracking inventory, processing orders — is optimised for writes and small transactional reads. Running analytical queries against this database (revenue by region for Q3, top 50 products by margin this year, customer cohort retention curves) is problematic at scale: it is slow, consumes resources that affect production performance, and requires complex queries against a normalised schema.

The separation is: transactional database (OLTP) for daily operations; analytical database (OLAP) for reporting and business intelligence.

At small scale (under 1M records per table): a read replica of your PostgreSQL database, queried through a BI tool like Metabase or Grafana, is sufficient. The queries run against the replica and do not affect production performance.

At growing scale: a separate analytical store populated by an ETL process from the production database. ClickHouse (column-oriented, extremely fast analytical queries, open source) is the current leading option for organisations that want control over their data. BigQuery (Google, serverless, billed per query) is the lowest-friction option for organisations comfortable with Google Cloud. Redshift (AWS) is an established option with af-south-1 availability.

For most Nigerian business applications at the ₦200M–₦2B revenue scale, a well-indexed PostgreSQL read replica with Metabase on top handles reporting requirements and costs under ₦50,000/month in infrastructure.

The Backup and Recovery Configuration

Nigerian businesses are more likely to experience infrastructure failures — power events, ISP outages, hardware failures in co-located servers — than comparable businesses in markets with more reliable infrastructure. Database backup configuration deserves explicit attention:

Daily automated backups to a separate storage location (not the same server) at minimum
Point-in-time recovery (PITR) for databases where data loss tolerance is low (financial systems warranting second-granularity recovery)
Cross-region or offline backup for business-critical data (AWS af-south-1 to eu-west-1 replication, for example)
Regular backup restoration tests — a backup that has never been tested is not a backup

Managed database services (Neon, Railway, Render, RDS) handle most of this automatically. For self-managed PostgreSQL, pgBackRest provides PITR with S3-compatible backup to Cloudflare R2 or AWS S3.

The database choice is consequential and relatively permanent — migrating a production database to a different engine mid-lifecycle is expensive and disruptive. The right choice for most Nigerian business applications is PostgreSQL, hosted in the nearest available cloud region to your users, with managed backups and a read replica for reporting.

Microservices vs Monolith for Nigerian Businesses — Choosing the right architecture for your scale
Offline-First Applications for Nigerian Users — Building for unreliable connectivity
Why We Build on the Edge: Cloudflare Workers in Africa — Edge computing for African latency challenges