Kviklet puts a pull request in front of every production query

The four-eyes principle applied to SQL

Kviklet, pronounced Quick-let, applies the Four-Eyes Principle to production database access, with a pull request-like review and approval workflow for individual SQL statements or time-limited database sessions. The stated purpose is secure access to production environments without impairing developer productivity, and the problem it attacks is specific. A team that needs production access has two bad options: hand out credentials and lose the audit trail, or route every query through a DBA or operations team and lose the engineers' time. Kviklet sits between them. Engineers can review and approve each other's requests without routing every query through a DBA or operations team, and the interface deliberately borrows the vocabulary of code review, with all data requests living in one place, described as like open pull requests for your production databases. The supported databases are Postgres, MySQL, MariaDB, MS SQL Server and MongoDB, so the tool is not tied to one vendor's data.

Requests are made against connections, not databases

The access model starts with identity, and the project recommends connecting Kviklet to your existing identity provider. Single sign-on is supported through OIDC, with Google and Keycloak named as examples, or through SAML, which is enterprise only, and LDAP authentication is supported for things like Active Directory. Once a user is authenticated, they create a request for a connection, and a connection maps to a specific database user rather than to a database in the abstract. That indirection is what makes the review meaningful, because the review is about a particular set of privileges on a particular account. There are two request types. A Single Query is a specific SQL statement submitted for review, and Temporary Access is a time-limited session in which multiple statements can be run. Depending on configuration, requests are reviewed and approved by other users before execution is allowed. The credential handling is the part that matters most: Kviklet connects to the database on the user's behalf, and the connection's database password is never shown to the user.

Review gates are configured per role and per connection

An admin configures which role has access to which connection and which review gates are required for execution. The database-level access itself is managed through the underlying database's own RBAC mechanisms, which is a sensible division of labour. The example in the documentation is that you can create a read-only role for a read-only connection and assign fewer review requirements for it than for a write connection. So the review burden follows the risk of the operation, and the actual privilege enforcement stays where the database already enforces privileges. Kviklet also records executed statements and associates them with the user and the access request, so the audit log is the point of the whole arrangement. The documentation is blunt about the corollary: for complete coverage of manual database access you have to restrict direct connections and route any manual access through Kviklet. Engineers do not need to receive or share the underlying database credentials, but that only holds if nobody is left with a direct path.

Not every feature exists for every database

The feature matrix is the most useful section of the documentation for an adopter, because it is explicit about gaps rather than quietly narrowing the claims. Statement review and temporary access are available for every database in the list, which covers Postgres, MySQL, MariaDB, SQL Server, MongoDB and Kubernetes. The proxy is marked as beta and is available for Postgres, MySQL and MariaDB only, with a cross for SQL Server and MongoDB. Explain Plan is available for Postgres, MySQL, MariaDB and SQL Server, with a cross for MongoDB and Kubernetes, and Kubernetes has a cross for temporary access as well, so a Kubernetes connection gets statement review and nothing else. The proxy feature is the interesting one for the enterprise tier, since it lets a user run their preferred database client through an approved temporary-access session with a temporary password, and the executed statements are still recorded in the audit log. That is the feature that lets a team keep using the tooling its engineers already know, and it is only available for three of the five databases.

Self-hosted with a Docker image and a Postgres for state

Kviklet is self-hosted and runs as a Docker container with a PostgreSQL database for its own application state, and the web interface is where you submit, review and execute requests. The available versions are published as releases and the documentation recommends regularly updating the version in use as new features are built. The image is published on GitHub's container registry, and the current recommended tag is ghcr.io/kviklet/kviklet:0.8.0, with :main offered as an alternative that the documentation warns might occasionally contain something buggy that slipped through a merge. The quick start compose file sets up three services, the sample Postgres that Kviklet will point at, a second Postgres for Kviklet's own state, and the Kviklet container itself.

  kviklet-postgres:
    image: postgres:16
    restart: always
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: kviklet
    ports:
      - "5433:5432"
    volumes:
      - ./kviklet-postgres-data:/var/lib/postgresql/data

The Kviklet service is configured through Spring datasource environment variables, with SPRING_DATASOURCE_URL pointing at the state database, plus INITIAL_USER_EMAIL and INITIAL_USER_PASSWORD for the first login. The build itself is a Kotlin backend on Gradle with a Node frontend.

FROM gradle:8.14.3-jdk21 AS build
WORKDIR /home/gradle/src

The Dockerfile then uses jlink to assemble a trimmed Java runtime, and the comment in the build explains that the module list comes from jdeps plus modules that are loaded reflectively or through the service loader, including the Kerberos modules for MSSQL integrated authentication and the JNDI DNS provider for LDAP server discovery.

Running it for the first time

The quick start is deliberately minimal. You start the compose file with docker-compose up -d, Kviklet comes up on port 80, and you open localhost in a browser. The admin login is [email protected] with admin as the password, which is fine for a trial and obviously has to change before anyone else can reach it. The compose file also contains an extra Postgres instance so you can set up a connection in Kviklet and try the request and review flow against something, and the sample data is loaded by mounting a SQL file into the database's init directory. The repository layout shows the surrounding project, with backend/ and frontend/ for the two halves of the application, charts/ holding the Helm chart, e2e/ with its own compose file and an examples/ directory containing certificates, plus run.sh and sample_data.sql. The Helm chart is worth noting for anyone running this on Kubernetes, since the tool is explicitly aimed at teams that deploy infrastructure that way. The last push to the repository was on 2026-10-17, and the release history shows 0.9.0 on 2026-09-21, 0.9.1 on 2026-09-27 and 0.9.2 on 2026-09-29, so the project is moving quickly through the 0.x line.

Where the paid tier and the custom licence come in

The licence is the first thing to check, and it is not an open source licence. The repository is filed under a custom licence that GitHub cannot classify, and the details are in the LICENSE.md file at the root, which is the place to look before you deploy it. The feature split follows the same pattern. An optional enterprise licence enables SAML authentication, role-based review requirements, role sync and API keys, and a request goes to the vendor site to obtain it. Role sync, which automatically pulls user roles from your identity provider groups, and role-based review gates, which require approvals from specific roles before execution, are the two features that most change how the tool behaves, and both are in the paid set. API keys for programmatic access to the Kviklet API is a third. The open tier is not a toy, since SSO through OIDC, LDAP, the review flow, the audit log and connection-level RBAC are all in it, but the paid tier is where the fine-grained control lives. The proxy feature is also an enterprise item for Postgres, MariaDB and MySQL. The practical warning is about the combination. A team that wants SAML because its identity provider cannot issue OIDC, plus role sync because its groups already map to database roles, is buying the product, and should price that against the cost of building the same workflow in house.

Editorial conclusion

Adopt Kviklet if your engineers need production database access today and your problem is that credentials are being shared by hand, because a reviewed request with an audit log fixes that without changing how people work. Skip it if a single DBA team already reviews every query, because the four-eyes workflow adds a second system to maintain, and skip it if the enterprise features are the point, since SAML, role sync, role based review gates and API keys all require a paid licence. Before you deploy, read the feature matrix for your specific database, since the proxy is missing for SQL Server and MongoDB and the Explain Plan view is missing for MongoDB and Kubernetes, and check which image tag you pin, because the :main tag is described as occasionally containing something buggy.

Frequently asked questions

Official sources

1. Issues
2. kviklet/kviklet on GitHub
3. Project website
4. README
5. Releases