Snowflake

PostgreSQL does more analytics than it is usually given credit for. A read replica with good indexing serves reporting comfortably into the hundreds of gigabytes, and where that covers the requirement, it is the cheaper and simpler answer.

Snowflake earns its place when the shape of the work changes: terabyte scans a row store cannot answer in useful time, many concurrent analytical users, continuous semi-structured feeds, or data shared with other organisations under governance. Any one of those justifies it. The transactional database is a separate question, and it stays in PostgreSQL.

Consolidation pays where the estate has accreted: a legacy warehouse, an export-driven reporting database, and a lake with no owner, each with its own pipelines and access model. Bringing them onto one platform collapses the pipeline count and puts a single role hierarchy and masking policy over data that previously had three.

Sequencing matters more than the destination. Warehouse workloads move first, because dbt models port most cleanly; the long tail of reports and extracts moves last, once the data it depends on already flows. We run consolidations in that order, keeping the old platform readable until nothing reads from it.

The SQL side works well. The language corpus is deep, Snowflake's information schema gives an agent the tables, types and constraints to write against, and dbt tests give generated transformations a fast correctness check.

What an agent does not see is the meter. A query can be correct and still scan a terabyte that a well-clustered table would prune, or hold an oversized warehouse resumed, and nothing in the code signals either. Generated work is therefore reviewed against query profiles and credit consumption as well as correctness, and that review stays with human engineers. The measured results of our AI-augmented delivery flow are on the Technology page.

Either as a fixed cost for an initial outcome, such as a first release or a defined migration, or as a monthly rate for the team once later phases are under way. We do not publish a figure for a build, because the scale is set by the number of features, platforms, user groups and users, and projects have run from four weeks to several months. The How We Charge page sets out both models, milestone billing and the notice period.

Typically one full-time engineer on the build, with two part-time roles alongside: one running the project and one working with you on priorities and technical decisions. Teams are shaped around the system rather than around one technology, so Snowflake work draws in the neighbouring stack when it needs to. Delivery starts under Australian leadership, with the engineering in our Manila delivery centre.

Discovery establishes the scope, systems involved and delivery requirements. We agree the implementation plan and timing after that work, before implementation begins.