Technology · 06 Data & Databases
Your database outlives every framework in front of it. We default to PostgreSQL, add Redis, document stores, vector search or a warehouse only when the workload asks for it, and hand over schemas, migrations and backups you own outright.
Updated September 2026 You own everything Reply within one business day
Forecast engine
Demand forecast - next 8 weeks
94.2%
Accuracy
+18%
Vs baseline
8w
Horizon
Retrained nightly on 14 months of order behaviour.
OlDevs, a full-stack studio in Vancouver, treats the database as the longest-lived part of a system and chooses it for the team who will maintain it.PostgreSQL is the default, with MySQL for WordPress, SQLite for edge cases, Redis or Valkey for caching and queues, pgvector for AI features, and a warehouse only once reporting outgrows the primary database. Every schema ships with tested migrations, encrypted backups and a written retention policy, all owned by the client.
Key facts
06 · Data & Databases
Each card says when the option is the right call, and what it will cost you to keep running.
The right choice for almost every transactional system: member records, orders, bookings, content, audit logs. JSONB, full-text search and pgvector mean one engine covers most needs. Later cost: a managed instance to patch and scale, and a team comfortable with SQL and query plans.
Right when the application already expects it: WordPress, WooCommerce, older PHP and Java systems. We keep these healthy rather than migrate for the sake of it. Later cost: two engines to back up and monitor if a PostgreSQL app sits beside them, so we consolidate only when a rebuild is already funded.
Right for mobile apps, offline-first tools, kiosks and small services at the edge, where a single file with no server process is the whole point. Later cost: it does not share well between many writers, so we plan a sync layer or a move to PostgreSQL before concurrent traffic arrives.
Right when records are genuinely document-shaped and vary by type: product catalogues with many attribute sets, form submissions, activity logs. Later cost: relationships and reporting get harder as the product grows, and consistency rules end up living in application code instead of the database.
Right for sessions, rate limits, hot lookups and background job queues sitting in front of a relational database. Valkey is the open-source fork we deploy where licensing terms matter to the client. Later cost: memory is the bill, and anything that must survive a restart still needs a durable store behind it.
Right when a product needs semantic search, retrieval for LLM answers or recommendations from embeddings. We start with pgvector inside PostgreSQL and move to Pinecone or Weaviate only when index size or latency demands it. Later cost: embeddings must be regenerated whenever the embedding model changes.
Stack
Concrete tools, current at the time of writing; confirmed for your project at scoping.
Relational
Document, cache and search
Analytics and pipelines
Streaming and jobs
Migrations and schema tooling
Backups and protection
What changed
What moved in this area and what it means for your build.
Sep 2025
The release added an asynchronous I/O layer and smoother major-version upgrades. For clients: new builds start on 18 where the managed host offers it; existing 16 and 17 databases stay where they are until a tested upgrade path is available on that host.
2025
Redis 8 returned to an open-source licence, while Valkey kept growing with backing from the major cloud providers. For clients: the choice is now a hosting question rather than a legal one, and code written against either works on the other for everything we use.
2025
Serverless PostgreSQL platforms such as Neon and Supabase made per-branch database copies cheap, and Neon joined Databricks. For clients: every pull request can get its own copy of a realistic database, which catches migration mistakes before they reach production.
2025 to 2026
pgvector kept improving its index types and managed PostgreSQL providers now ship it by default. For clients: most AI search and retrieval features no longer need a separate vector database, which removes one bill, one sync job and one thing to secure.
2026
BigQuery, Snowflake and Databricks all deepened support for Apache Iceberg tables in object storage. For clients: analytics data can sit in your own cloud bucket in an open format, and the query engine on top can change without a migration project.
2025 to 2026
Quebec's Law 25 is fully in force with its own consent and portability duties, while federal reform stalled and remains unsettled at the time of writing. For clients: retention schedules and residency decisions now have to be written per province, not assumed nationally.
How we choose
We ask which team, in-house or ours, will be patching, tuning and restoring this database long after launch, and choose an engine they can hire for. A clever store nobody on staff understands is a liability the day the person who chose it leaves.
Public bodies, associations and regulated firms often need data in a Canadian region. AWS, Google Cloud and Azure all offer Canadian regions, but not every managed database or vector service is available in them, which can decide the product before performance does.
We look at what the application does thousands of times a day, not the edge cases in the pitch deck. Most systems are read-heavy with a handful of hot tables, which is a caching and indexing problem, not a reason to leave a relational database.
Schemas change monthly for the life of a product. We favour engines and migration tools that make an additive change safe, reversible and boring, because the cost of the hundredth migration matters more than the speed of the first insert.
Before discussing throughput we agree how much data you could stand to lose and how long you could be down. Those two numbers decide the backup schedule, replication, and whether a managed service or self-hosting is the honest answer.
Every additional store is another backup, another monitoring dashboard, another security review and another skill to hire. We add Redis, a document store, a vector index or a warehouse when the workload proves it needs one, and we say so in writing.
Who it's for
Whether the audience is a customer, a member, a citizen, or your own team, the choice has to hold up under real use.
Systems of record that must survive audits, staff turnover and acquisitions. We model core entities carefully, keep an audit trail on sensitive tables, encrypt at rest with keys you control, and document the schema so your own DBA or a future vendor can take over.
Member systems, registries and grant portals with personal information governed by PIPEDA, BC PIPA or provincial equivalents. We design for Canadian residency, role-based access, retention schedules and exports in open formats, and we build bilingual EN/FR data where content is public-facing.
One schema shared by many locations, with clean separation between head office and each franchisee. We use row-level security or per-tenant boundaries, consolidate location data into a warehouse for reporting, and keep order and loyalty data consistent across web, app and point of sale.
A database that will not need replacing at the first funding round. PostgreSQL with pgvector covers transactions, search and early AI features in one place, database branching keeps previews cheap, and a written migration discipline means the schema can change weekly without fear.
Related technology
Seven runtimes, three API styles and the plumbing around them: sign-in, queues, caching, file storage, email…
Explore05AWS, Microsoft Azure and Google Cloud, plus Vercel and Cloudflare where a smaller footprint fits. Canadian…
Explore10Every OlDevs project ships with threat modelling, OWASP ASVS checks, encrypted data, single sign-on and audit…
ExploreFAQ
PostgreSQL handles relational data, JSON documents, full-text search and vector search in one engine with strong consistency guarantees, so most products never need a second store. MySQL stays where WordPress or an existing system depends on it, and MongoDB earns its place when records are genuinely document-shaped. We choose per project, but PostgreSQL wins most of the time.
Usually, yes. We use expand-and-contract migrations: add the new column or table, backfill in batches, switch reads, then remove the old structure once nothing uses it. For moves between engines or hosts we run logical replication or change data capture so both sides stay in sync until a short, scheduled cutover.
Wherever you need it to be. AWS, Google Cloud and Azure all run Canadian regions, and we place the primary database, replicas and backups inside them when residency is a requirement. Some managed vector or analytics services are not yet offered in Canada, and we tell you that before you commit to one.
We classify columns holding personal information at design time, encrypt the database at rest with a key in your cloud account, restrict access by role, and write a retention schedule that the application enforces with scheduled deletion or anonymisation. Exports and deletion requests are built as features, not handled by hand.
Not at the start. pgvector inside PostgreSQL handles semantic search and retrieval for most products, keeps embeddings next to the rows they describe, and avoids a second system to secure and back up. We move to Pinecone or Weaviate when index size, filtering needs or latency show that the primary database is the limit.
When reporting queries start slowing the production database, when several systems need joining for one view, or when finance wants history the application never kept. We then feed BigQuery, ClickHouse or Snowflake from the primary database and other sources, model it with dbt, and leave the transactional database to do its job.
Backups run continuously with point-in-time recovery, are encrypted, and are copied to a second region or account so a mistake in one place cannot erase everything. We restore a backup into a fresh environment on a schedule and record how long it took, because a backup nobody has restored is a hope, not a plan.
Let’s connect
Tell us what you’re building. We’ll reply within one business day with recommended platforms, structure and a tailored quote — no obligation.