Question 1

How do you migrate a live database without downtime?

Accepted Answer

By making the change reversible and incremental rather than a single switch. The standard approach is expand-and-contract: add the new column, table or database alongside the old, write to both, backfill historical rows in batches that do not lock the table, move reads across once the data is verified, then remove the old structure in a later release. Truly zero downtime depends on your stack and constraints, so we quote a realistic short cutover window instead of promising zero and discovering otherwise at two in the morning.

Question 2

Will optimisation break anything?

Accepted Answer

Index and query work is generally low risk when the changes are reviewed and applied one at a time, but there are real hazards: adding an index on a large table can lock writes if built the wrong way, and a query rewrite can subtly change results when NULLs or duplicates are involved. We test on a copy with production-sized data, apply index builds concurrently where the engine supports it, and compare query output before and after rather than assuming equivalence.

Question 3

Do you need access to our production database?

Accepted Answer

For diagnosis we usually need far less than people expect — execution plans, slow-query logs, schema definitions and table statistics are often enough, and none of those require reading customer records. Where direct access is genuinely necessary, we work through a named read-only role, and for any work involving personal data we prefer a masked or reduced copy. Write access to production is granted for a specific migration window, not permanently.

Question 4

Our hosting bill keeps rising but traffic has not. Why?

Accepted Answer

On managed Postgres platforms, data transfer and storage are often billed separately from compute, and an application that reads whole tables where it needs three columns, or refetches the same rows on every request, generates far more transfer than its traffic suggests. We have chased exactly this on our own platform and reduced it by replacing full-table reads with narrow projections, batching inserts, converting per-row round-trips into aggregate SQL, and adding a caching layer with deliberate invalidation.

Question 5

We keep getting connection-limit errors after moving to serverless. What is wrong?

Accepted Answer

Serverless functions scale out horizontally, and each instance can hold its own connections, so a platform that comfortably served a single long-lived application server can exhaust its connection limit quickly. The fix is a properly placed connection pooler, a client configured for it, short transactions, and moving work that does not need a live connection out of the request path. This is a design issue rather than a capacity issue, and buying a bigger instance rarely solves it.

Question 6

How do you decide between normalising and denormalising?

Accepted Answer

By what the data has to guarantee versus how it is read. Normalisation prevents contradictory data and is the right default for anything transactional; denormalisation is a deliberate performance decision that you pay for with update complexity and the risk of drift. We denormalise where a join is provably expensive on hot paths, keep the derived data maintained by the database or a single code path, and write down why it exists so nobody undoes it by accident.

Question 7

How do you find missing indexes?

Accepted Answer

By looking at real workload rather than guessing: slow-query logs, execution plans showing sequential scans on large tables, and index-usage statistics that reveal both unused indexes and hot tables with no supporting index. Composite index column order matters as much as which columns are included, and partial indexes often outperform broad ones for filtered queries. We also check the write side, because every index makes inserts and updates more expensive.

Question 8

What happens to our data if we stop working with you?

Accepted Answer

It stays where it always was — in your database, under your account. We do not host client production data on infrastructure we own unless you specifically ask us to, and we do not keep copies after an engagement ends beyond what is needed for an agreed handover. You receive the schema documentation, migration history, index rationale and recovery procedure, and we can brief whoever takes over.

Question 9

Can you work with our existing hosting and database provider?

Accepted Answer

Yes. We work regularly with managed PostgreSQL such as Neon and comparable providers, with MySQL on conventional hosting, and with self-managed instances on a VPS, and we do not require a platform change to start. If the current platform is genuinely the constraint — no point-in-time recovery, no read replica option, a version that is out of support — we will document why and price the alternative rather than simply asserting it.

Question 10

How are backups and point-in-time recovery handled?

Accepted Answer

We agree the acceptable data-loss window and recovery time first, because those two numbers determine everything else, then configure backups and retention to match and verify them with a real restore into a separate environment. We also document who can trigger recovery and how long a full restore actually takes on your data volume, since that measurement is worthless when taken for the first time during an incident.

Question 11

Do you handle multi-tenant data isolation?

Accepted Answer

Yes, and we treat it as a schema concern rather than a coding discipline. Every tenant-scoped table carries a tenant key, access goes through queries that cannot omit it, and row-level security enforces the boundary at the database rather than relying on every developer remembering a WHERE clause. We built this pattern into a multi-tenant AI support platform for ikas stores, including per-tenant usage and cost tracking.

How can we help?

Database Services
FAQ

Helpful
information

Getting Started

Timeline

Pricing

Support

Still have questions?

Database ServicesFAQ

Helpfulinformation