Skip to content
DataKlin

0.3.0

Released

DataKlin 0.3.0 is the AWS release. It adds Amazon Aurora and Amazon RDS connections for PostgreSQL and MySQL with AWS IAM authentication and AWS Secrets Manager, TLS for PostgreSQL and MySQL, enforced read-only connections and confirmations for destructive statements. It is also the first macOS build that is signed and notarized by Apple, and macOS builds now require Apple silicon. If you are coming from 0.2.0, everything below is new to you. It is the same build as 0.3.0-rc.2, with only the version number changed.

Added

  • Amazon Aurora and Amazon RDS. Four new entries in the new-connection picker: Amazon Aurora PostgreSQL, Amazon Aurora MySQL, Amazon RDS for PostgreSQL and Amazon RDS for MySQL. Each opens the PostgreSQL or MySQL connection form already set to verified TLS (Verify full) with the built-in Amazon RDS certificate bundle, and to AWS IAM authentication. DataKlin recognises cluster, reader, custom and instance endpoints and fills in the region from the host name. It offers to open a reader endpoint’s connection read-only, shows the Aurora version and the instance’s role when you test a connection, and explains a failover or a resuming Aurora Serverless v2 cluster when an error looks like one.
  • AWS authentication. Two new authentication methods for PostgreSQL and MySQL: AWS IAM, which signs a fresh IAM database token for every new connection to the server, so long sessions and cancels keep working after the 15-minute token lifetime, and AWS Secrets Manager, which reads the user name and password from a secret, such as an RDS-managed master user secret. AWS credentials come from a named profile (including IAM Identity Center (SSO) and assume-role profiles), the default credential chain, or access keys kept in your operating system’s secure storage. Test the credentials from the connection form before you connect. When an SSO session has expired, DataKlin tells you to run aws sso login and reconnect.
  • TLS for PostgreSQL and MySQL (and MariaDB). A new Security tab in the connection form sets the TLS mode (Disable, Require, Verify CA or Verify full), the certificate authority (a file, pasted PEM text or the built-in Amazon RDS bundle), a PEM client certificate and key, the TLS server name and the minimum TLS version. New connections to a remote host default to Verify full; new connections to localhost, 127.0.0.1 or ::1 default to not encrypted. When a certificate can’t be verified, DataKlin explains why (untrusted, expired, wrong host name, client certificate required) and how to fix it. There is no “trust anyway” button. The console status bar shows each connection’s TLS status.
  • Production safety. Destructive statements (DROP, TRUNCATE, DELETE or UPDATE without a WHERE, and similar) ask for confirmation before they run. On a connection tagged production, the confirmation always appears and you type the database name to confirm. Production connections are marked in their console tabs, result panels, window title, status bar and a banner in each console. A new production connection starts read-only, which you can turn off. Choosing a weaker TLS mode for a production connection also asks for confirmation.

Changed

  • Read-only connections are enforced. In 0.1.0 and 0.2.0 the read-only marker was a label only. Now DataKlin checks every statement before it reaches the database, and refuses writes, schema changes and statements it can’t classify on a read-only connection. Where the database supports it (PostgreSQL, MySQL, MariaDB, SQLite), the session itself is also put into read-only mode. A status bar control and a command toggle read-only for an open connection; turning it off on a production connection asks first.
  • macOS builds are signed and notarized. The macOS build is signed with a Developer ID and notarized by Apple, so macOS opens it without the “could not verify” warning and without the Control-click workaround. When you first start 0.3.0 after 0.2.0 or earlier, macOS asks once whether DataKlin may use “DataKlin Safe Storage” in your keychain: choose Always Allow so your saved passwords keep working.
  • macOS builds now require Apple silicon. There is no Intel (x64) macOS build from 0.3.0. Intel Macs can keep using 0.2.0. Windows and Linux builds are unchanged (x64).

Fixed

  • MySQL and MariaDB error messages could show most of the connection password. See Security below.

Security

  • MySQL password leak in error messages. When the server cut a syntax-error snippet right after a password, and the password’s first and last characters were the same, the error shown could contain all but the last character of the password. The whole password is now always masked. This affected MySQL and MariaDB connections in 0.2.0.
  • Hardening found in the security reviews of this release:
    • Verify CA trusts only the certificate authority you choose, never the system’s public roots. With the Amazon RDS bundle, the Security tab recommends Verify full, because Verify CA alone accepts the certificate of any RDS endpoint.
    • The not-encrypted default for localhost doesn’t stay when you change the host to a remote one, and no error screen offers a one-click switch to a weaker TLS mode.
    • Certificate and key files on network shares or device paths are refused.
    • MySQL sends a cleartext password (needed for IAM tokens) only over Verify CA or Verify full.
    • AWS IAM and AWS Secrets Manager connections require verified TLS, except to the local machine, and an IAM token is signed only for the connection’s own host (or for the signing host you set when you forward a port to localhost).
    • A credential_process helper from an AWS profile runs with a time limit and an output size limit, and without DataKlin’s own sensitive environment variables.
    • Detecting Aurora MySQL no longer calls a function that a database user could replace with a stored function of their own.
    • The statement checks read MySQL and MariaDB executable comments (/*! ... */) the way the server does, so a write or a DELIMITER hidden in one is still caught.

Extension API

  • @dataklin/extension-api and @dataklin/extension-test-kit move from 0.1.0 to 0.3.0. There is no API 0.2: the API version follows the milestone it ships with. Every built-in extension moved to engines.dataklin ^0.3.0.
  • Breaking: an extension that declares ^0.1.0 no longer loads, because a 0.x caret range pins the minor version. A security declaration whose default TLS mode doesn’t verify the server, while it declares a verifying mode, is refused. Connectors written against 0.1 compile unchanged.
  • Added: the confirmation protocol (CONFIRMATION_REQUIRED, ExecuteRequest.confirmed, POLICY_UNAVAILABLE); the documents, keyValue and text result kinds with applyEdit, describeEdit, EDIT_CONFLICT and openNode, plus their core viewers and document editor (no built-in extension uses them yet; Redis and DynamoDB will in 0.4.0); TLS and authentication helpers; the awsIam, awsSecret and awsCredentials authentication methods with ConnectParams.renewAuth; and contributes.connectionPresets. The test kit adds the security and result-kinds conformance suites.
  • The full list is in packages/extension-api/CHANGELOG.md and packages/extension-test-kit/CHANGELOG.md. Installing third-party extensions still isn’t supported, and the packages aren’t published to npm.

Known issues

  • Real-AWS checks are pending. The AWS features were tested against local stand-ins (a local AWS emulator, and PostgreSQL and MySQL servers using TLS with test tokens), not real AWS. The checks on real Aurora clusters (IAM Identity Center profiles, IAM authentication on cluster, reader and custom endpoints, Secrets Manager master users, a paused Serverless v2 cluster) are still to be done.
  • Aurora through SSM port forwarding needs the TLS server name. When you connect to an Aurora or RDS endpoint forwarded to localhost (for example with AWS Systems Manager), set the signing host and also set the TLS server name in the Security tab to the endpoint’s host name by hand. Otherwise Verify full fails, because DataKlin checks the certificate against localhost.
  • Secrets Manager rotation with alternating users. PostgreSQL connections keep the first user name they read from the secret, so a rotation that switches between two users fails until you reconnect. MySQL is not affected.
  • Connections saved before 0.3.0 still don’t use TLS. Their behaviour doesn’t change on upgrade: open the Security tab and choose a TLS mode to encrypt them.
  • No SSH tunnels yet, and no “prefer” TLS mode. Both are planned for 0.4.0. Cassandra connections are still plaintext only.
  • No in-app AWS sign-in. DataKlin can’t start an SSO sign-in or ask for an MFA code: run aws sso login (or sign in with your usual tool) before you connect.
  • Windows builds aren’t signed. Windows SmartScreen warns when you first open DataKlin. There is no auto-update yet on any platform: to update, download the new version.
  • SQLite. Cancelling a long statement that runs as a single step stops it from the user’s point of view, but it keeps using one CPU core in the background until that step finishes. Very large TEXT values show as a capped “unsupported” cell.
  • Cassandra. With peer discovery on (the default), your credentials are sent to every node in the local data center; to limit them to the hosts you list, choose “Contact points only”. Cancel is client-side: DataKlin stops waiting for the result, but the server may finish the query.
  • History file growth. While DataKlin is running, the history database’s write-ahead log (app.db-wal) grows with each statement run. It shrinks when you clear or prune history, or at the next start after a crash.
  • History erasure. Deleting some history entries, or clearing one connection’s history, can leave fragments of the removed statements in the local database file until it is compacted. Clearing all history leaves none.

All release notes

© 2026 DataKlin contributors

This site uses no cookies, analytics or trackers.