# How PropertyGuru Runs Database Governance as Code with Bytebase

> How PropertyGuru automates database changes and access by managing projects, permissions, and policies as code with Bytebase.

2026-07-17 | Source: https://www.bytebase.com/customers/propertyguru/

---

> [PropertyGuru](https://www.propertygurugroup.com) is Southeast Asia's leading PropTech company, the destination for over 30 million monthly property seekers looking for a home across Singapore, Malaysia, Thailand, and Vietnam. By adopting Bytebase, PropertyGuru's engineering team turned database changes and access, once SQL scripts executed by hand by the infrastructure team, into a self-service workflow governed entirely as code.

**With Bytebase, PropertyGuru:**

- Made database migrations **self-service for its 80+ developers**, instead of SQL files waiting on the infrastructure team
- **Cut its reliance on the infrastructure team** for migrations and access requests, including outside office hours
- **Significantly reduced tech-support tickets** for database migration and access workflows
- Governs **more than 200 databases** across SQL Server, MySQL, PostgreSQL, and MongoDB, with every policy defined once and enforced automatically, including its ISO 27001 90-day access reviews

![Before and after: PropertyGuru's database change workflow, from manually executed scripts to self-service governed by code](/content/customers/propertyguru/before-after.svg)

## When Every Migration Waited on Infra

Before Bytebase, a database change at PropertyGuru was a SQL migration file committed to GitHub, and then a wait. The infrastructure team picked up each script and executed it by hand against the target databases. Access requests ran through the same team. The process worked, but it put one team in the critical path of every database change and every access grant, and the queue did not care about office hours: a developer blocked in the evening stayed blocked until someone from infra was available.

The estate being governed is not small. PropertyGuru manages more than 200 databases across SQL Server, MySQL, PostgreSQL, and MongoDB: a mix of legacy shared databases used by multiple teams and per-team microservice databases, spread over various environments. On top of that, ISO 27001 compliance requires developer database access to be reviewed every 90 days.

## The Goal Was Automation; The Method Was Code

From the first week, the team's goal was to automate database changes and secure database access, and they drew a firm conclusion about how: if it is going to be automated, it has to be code. Rather than administering Bytebase through its console, team leads provision projects and assign access programmatically, the same way they manage the rest of their infrastructure. The setup started on the [Bytebase API](https://api.bytebase.com), with scripts that created projects, registered users, and set IAM policies, and matured into the [Bytebase Terraform provider](https://registry.terraform.io/providers/bytebase/bytebase/latest/docs), where the whole structure is declared instead of scripted.

What lives in that Terraform configuration is the governance itself: projects and their database scopes, project memberships via the `bytebase_iam_policy` resource, and role bindings (who owns a project, who develops in it, who can query what). Standing up a new team, granting a team access to a legacy database, or tightening a permission is a pull request: reviewed like code, versioned like code, and traceable to a commit when an auditor asks who had access and since when.

Identity flows in from the company directory: Microsoft Entra ID [syncs users and groups into Bytebase via SCIM](https://docs.bytebase.com/administration/scim/overview/), and Terraform binds roles to [groups](https://docs.bytebase.com/administration/user-groups/) rather than individuals. When someone joins a team, they inherit the team's database permissions; when they leave, the permissions go with them. Group bindings reference the same group emails Entra ID syncs in, so the Terraform code stays readable: no resolving directory object IDs by hand.

The declarative baseline coexists with what happens at runtime. Terraform defines the standing structure (projects, teams, long-lived roles) while time-boxed access requested through Bytebase's own workflow is granted and expires outside of it. Early on, a `terraform apply` could wipe those runtime grants; PropertyGuru surfaced the conflict, and the provider now preserves requested roles when the declared policy is applied. It is the detail that makes governance-as-code workable in practice: the repository stays the source of truth for structure without fighting the just-in-time grants developers rely on day to day.

## Self-Service Migrations, With Guardrails Where They Matter

Developers now submit database changes directly in Bytebase, following an internal step-by-step guide the team wrote. Every change is validated by [SQL Review](https://docs.bytebase.com/sql-review/review-policy), one set of rules applied uniformly across every environment, before a human ever looks at it, and production changes route through an [approval flow](https://docs.bytebase.com/change-database/approval) from project owner to DBA.

The guardrails are deliberately uneven. In non-production environments, the team disabled the approval flow entirely: developers modify those databases with no blocker at all, while production keeps its full review chain. That one policy decision removed a steady source of friction on both sides: developers stopped waiting, and the infrastructure team stopped executing routine scripts. In the team's own words, developers save hours on feature work that touches the database, and supporters shed "tons of toil" from running migration scripts by hand.

Slack ties the loop together: [webhook notifications](https://docs.bytebase.com/change-database/webhook/) tell approvers when a change is waiting and tell developers the moment it is approved.

## Access on a Compliance Clock

Database access follows the same self-service pattern. Developers request [just-in-time access](https://docs.bytebase.com/security/database-permission/just-in-time) scoped to the databases they need, and every grant carries an [expiration](https://docs.bytebase.com/security/database-permission/expiration), which turns the ISO 27001 rule that access must be reviewed every 90 days from a manually tracked obligation into a property of the system. Bytebase reminds users before a role expires, so access lapses on schedule without cutting someone off in the middle of an emergency.

Queries themselves run in the [SQL Editor](https://docs.bytebase.com/sql-editor/overview/), where [dynamic data masking](https://docs.bytebase.com/security/data-masking/overview/) applies global rules automatically: project owners see full data, while querier-role users see masked columns. Like everything else in the setup, the masking policy is defined once and enforced on every query.

## Two Years In

PropertyGuru runs Bytebase self-hosted on its own infrastructure, behind a zero-trust access layer, with database credentials held in an external secrets manager rather than in Bytebase itself. The setup has run in production for two years, through steady weekly change traffic on the databases behind PropertyGuru's marketplaces.

The outcomes the team reports are the ones the original goal called for: self-service migration requests that improved developer velocity, reduced dependency on the infrastructure team, particularly outside office hours, and a significant drop in support tickets for database migration and access workflows.

## Governance That Compounds

What makes PropertyGuru's setup worth studying is that none of it depends on discipline. The policies (who can access what, which changes need whose approval, what gets masked, when access expires) are not settings someone remembers to configure. They are code: reviewed like code, versioned like code, and enforced by the platform on every change and every query. Two years in, that is what lets PropertyGuru govern more than 200 databases without the infrastructure team becoming the bottleneck it set out to remove.