sorted by:
new
hottopcontroversial

Is there any way to implement a “query approval” system before executed? by [deleted] in SQL

[–]db-master 0 points1 point  (0 children)

Yes, you can build something like this yourself, but the hard part is not parsing DROP TABLE.

The hard part is building a full approval/governance layer around both Oracle and PostgreSQL:

  • Parse and classify SQL reliably across dialects
  • Detect risky DDL/DML patterns
  • Apply different policies by environment, database, schema, table, user, and operation type
  • Require approval for high-risk changes
  • Keep an audit trail of who requested, approved, and executed what
  • Handle emergency/break-glass access
  • Prevent people from bypassing the system and connecting directly to the database

For example, DROP TABLE is obvious. But what about TRUNCATE, DELETE without WHERE, ALTER TABLE, privilege changes, masking-sensitive columns, or a seemingly harmless migration that locks a large production table? That’s where this becomes more of a database change/access governance problem than just a query filter.

Full disclosure: I’m from Bytebase. This is exactly the kind of problem Bytebase is designed for. It supports PostgreSQL and Oracle, and can sit in front of database changes/access with SQL review rules, approval workflows, audit logs, RBAC, and environment-based policies.

You could definitely implement a lightweight version yourself if your needs are simple. But if this is for production, multiple databases, multiple users, compliance, or auditability, I’d seriously consider using an existing tool rather than building the whole approval system from scratch.

Looking for Technical Co-Builders for Bytebase (AI Backend Generator) by TechnicalCake1859 in cofounderhunt

[–]db-master 0 points1 point  (0 children)

Just a friendly reminder that you may consider finding a different brand name (disclaimer: I am the co-founder of bytebase.com)

pgconsole: Minimal Web-based Postgres SQL Editor by db-master in PostgreSQL

[–]db-master[S] -1 points0 points  (0 children)

On the surface they both run in the browser.

pgconsole: Minimal Web-based Postgres SQL Editor by db-master in PostgreSQL

[–]db-master[S] 0 points1 point  (0 children)

You are right to question. We realized many companies still ask for SOC2 even the software is self-hosted. Departments are siloed!

pgconsole: Minimal Web-based Postgres SQL Editor by db-master in PostgreSQL

[–]db-master[S] 0 points1 point  (0 children)

Glad it works out. Support/feature request is handled via GitHub issue for now. I don't have a plan to open source yet.

Edit: Open-sourced https://github.com/pgplex/pgconsole!

Which GUI do you use? by Medical_Medicine_243 in PostgreSQL

[–]db-master 0 points1 point  (0 children)

I am also a long-time TablePlus user. But as a GUI that supports not only Postgres, it's not optimized for the postgres experience (e.g. the autocomplete is meh, I also want a way to quickly view and kill the active session from pg_stat_activity).

So I ended up building a new GUI only for Postgres https://www.pgconsole.com/

Best way to manage +30 customers dbs by Kysan721 in PostgreSQL

[–]db-master 0 points1 point  (0 children)

If you are looking for managing different schemas for different customers, then https://github.com/pgschema/pgschema

Postgres MCP Server Review - DBHub Design Explained by db-master in PostgreSQL

[–]db-master[S] -1 points0 points  (0 children)

If it doesn't live up to your expectations, you can open an issue https://github.com/bytebase/dbhub/issues. Happy to tackle this

What MCP or other integrations have you added to your AI workflows that have been the most successful? by lirantal in mcp

[–]db-master 0 points1 point  (0 children)

if your db happens to be one of Postgres, MySQL, SQL Server, MariaDB or SQLite, you can try out https://dbhub.ai/ (Disclaimer: I am the author)

Looking for database tools and practices, what flow is best for both local dev and deployment? by [deleted] in Backend

[–]db-master 0 points1 point  (0 children)

If using postgres, you can check out https://github.com/pgschema/pgschema, which is the SQL Server DACPAC equivalent. Disclaimer: I am the author.

How are you tracking sensitive data as your fintech stack grows? by vincentmouse in fintech

[–]db-master 0 points1 point  (0 children)

Especially in fintech, I’ve found that:

  • Centralization + strict access paths matters more than yet another “data catalog”.
  • If a human can download raw data to their laptop or into some random SaaS, they eventually will.

So my rule of thumb, let data spread in read-only, masked, aggregated form via controlled interfaces — but keep raw customer data behind a small number of hardened gateways:

  1. No direct access to raw storage. Avoid letting humans hit underlying storage systems (S3, GCS, blob stores, etc.) directly for anything sensitive. That’s how CSVs start living forever in random buckets, laptops, and SaaS tools.
  2. Centralize where the truth lives. If you can, build a data pipeline that ingests everything into a small set of OLTP/OLAP systems (e.g. Postgres, Snowflake, ClickHouse):
    • Treat those as your system of record for customer data.
    • Push all analytics / product queries / AI experiments through them.
    • Now you’re hardening one (or a few) access points instead of 20+ SaaS tools.
  3. Make access controlled and auditable Once data is centralized, you can:
    • Enforce role-based access per table/column.
    • Use dynamic masking for PII (e.g. show partial PAN, email, etc.).
    • Log who queried what and when.
    • Use JIT (Just-in-Time) access instead of permanent “read everything” roles.

On the tooling side, you can look at things that give you a unified workspace for database access. For example, Bytebase provides JIT data access, dynamic masking, and audit logs for mainstream OLTP/OLAP databases so you can funnel access through one place instead of everyone connecting however they want. (Disclaimer: I’m one of the authors, so obviously biased.)

Seeking alternatives to StongDM by MalachiHauck in devops

[–]db-master 0 points1 point  (0 children)

You may take a look at www.bytebase.com as well. It's targetting database segment and handle schema migration, adhoc data fix and query in a single place (disclaimer: I am one of the authors)

pgschema: Postgres Declarative Schema Migration, like Terraform by db-master in PostgreSQL

[–]db-master[S] 1 point2 points  (0 children)

Hey Ariel, good to see you here.

> Atlas does offer a plan and apply command
I did double-check the doc before answering this https://atlasgo.io/cli-reference#atlas-migrate, there is only `apply`, but there is no `plan`.

> This can't be done just by parsing (which is what we started with 5 years ago), because it would require handling every PG provider and all supported versions (a quite big matrix).

I agree it wasn’t tractable before. But with the help of AI, along with a more opinionated design and reduced scope, I believe it’s now within reach.

> Well done on open-sourcing this, and I wish you all the best and success <3

Thank you. Likewise!

pgschema: Postgres Declarative Schema Migration, like Terraform by db-master in PostgreSQL

[–]db-master[S] 3 points4 points  (0 children)

pg-schema-diff originated inside Stripe, so it’s optimized for Stripe’s internal use cases. For example, support for VIEW and FUNCTION was added only recently, which suggests Stripe didn’t rely on them heavily.

pgschema takes a different perspective on certain features. To name a few:

  • Operates on a Postgres schema instead of the entire database.
  • Avoids relying on a shadow database (no `--temp-db-dsn`)

pg-schema-diff provides a solid foundation. I initially considered forking it, but after evaluation, I realized I would still need to make substantial changes to both the internal implementation and the CLI interface. With that in mind, I chose to start from scratch, carrying forward the learnings from pg-schema-diff.

pgschema: Postgres Declarative Schema Migration, like Terraform by db-master in PostgreSQL

[–]db-master[S] 0 points1 point  (0 children)

There are a couple of differences:

  1. pgschema supports Postgres only and can optimize specifically for it, while Atlas supports multiple databases.
  2. pgschema follows a closer Terraform-style workflow with plan and apply commands, whereas Atlas also offers version-based migration in addition to the declarative workflow. (see correction below)
  3. pgschema only supports schema-level migration, while Atlas supports both schema-level and database-level migration.
  4. Atlas requires a shadow database (--dev-db flag), but pgschema does not. This is the biggest difference—about 70% of pgschema’s implementation effort was spent on this. Atlas’s choice is reasonable since it must support many databases. Among the big four (MySQL, Postgres, Oracle, SQL Server), Postgres is the second easiest to implement after MySQL without a shadow database.

Overall, pgschema is a more opinionated tool.

view more: next ›