Discovery
Configuration → Discovery keeps a list of database servers and the databases found on them, so the inventory stays complete as servers gain and lose databases. Admins see the page; adding, changing, scanning and removing servers and adding found databases as connections need the Release Manager or Admin role and the Configuration section.
Servers
Add Server takes a name, the engine, the host and port (the engine's usual port to start), the username and password it signs in with, TLS, and for Oracle the service name. The password is encrypted at rest and never shown again; leaving it blank when editing keeps it. Discovery scans PostgreSQL, TimescaleDB, CockroachDB, MySQL, MariaDB, SQL Server, Oracle, MongoDB, Redis, Cassandra, Neo4j and Elasticsearch servers; SQLite has no server, so each SQLite file is added as a connection instead.
Each server's card shows its host, how many databases were found on it and when it was last scanned, with a mark for a scan that failed. Open a server to Scan Now, edit or remove it, and see its last scans: when, how many databases were found, how many were new and how many went missing, or the error when a scan failed.
Scheduled scans
Each server has a Scan schedule: only when asked (the default), every hour, every 6 hours, every day or every week. A scheduled server is scanned when its last scan is that old, and right away when it has never been scanned; the server checks every 30 seconds for servers that are due and scans them one at a time, so with several servers running DB Studio one of them scans. A scan that is still marked as running after 30 minutes, because the server restarted mid-scan, is started again. A scan the schedule started shows schedule in the server's scans, and a failed one is tried again at the next interval rather than at once.
The server's card shows Next with how soon the next scan is due, and its details show the schedule and the time of the last and next scans.
AWS accounts
Add AWS Account lets Discovery read the RDS and Aurora databases in an AWS account and register each as a server to scan. Give it a name, the regions to read, and how to reach the account: the ARN of a read-only role it assumes (with the role's external ID, when the role requires one), an access key, or both, in which case the key is the identity that assumes the role. Without an access key, DB Studio assumes the role with its own AWS identity, such as the instance or task role it runs under. The role needs only rds:DescribeDBInstances and rds:DescribeDBClusters. An endpoint URL is used instead of the public AWS endpoints, for a private endpoint or an AWS-compatible service. The secret access key is encrypted at rest and never shown again.
Sync Now reads each region: every Aurora cluster is registered by its cluster (writer) endpoint, and every RDS instance that is not a cluster member by its endpoint, as a server named identifier (region) with the engine mapped to PostgreSQL, MySQL, MariaDB, SQL Server or Oracle (Oracle with its database name as the service name). Registered servers sign in with the database username and password given on the account, or each database's master username when none is given, and scan on the account's schedule. Syncing again updates what changed without duplicating a server, a database no longer in AWS is marked no longer in AWS and not scanned, and engines Discovery does not scan, such as DocumentDB and Neptune, are counted as skipped. Each sync is recorded in the Audit Log as SYNC_AWS_ACCOUNT; a role that cannot be assumed or a region that cannot be read fails the sync with AWS's error and registers nothing. Removing an account removes the servers it registered; connections already added from them stay.
What a scan finds
A scan signs in with the server's credentials and lists what the engine holds: databases (with their size where the engine reports it) on PostgreSQL, TimescaleDB, CockroachDB, MySQL, MariaDB, SQL Server and MongoDB; schemas on Oracle; keyspaces on Cassandra; databases on Neo4j; logical databases with their key counts on Redis; and indices with their document count and size on Elasticsearch. A database found before but not this time is marked Missing.
Databases found
The table lists every database found, with its server, engine, size, owner, status (Found, Connection or Missing), tags and when it was last seen; search it by database, server or tag and filter it by status. Add tag picks a tag or creates one.
Add as Connection turns a found database into a DB DevOps connection to that database on the server, signed in with the server's credentials, with the name and environment you choose. It is tested and placed like any connection you add yourself, and the database's status becomes Connection; the change is recorded in the Audit Log as ADD_DISCOVERED_CONNECTION.