Connect a data source
Choose a direct connection, SSH server or supported local file.
The database must be reachable from the BytesMap host that executes the read. In a cloud deployment, localhost means that service or container. In a local desktop host, it means the local machine.
Choose a connection
| Connection | Use it for | Check before connecting |
|---|---|---|
| Direct database | A reachable PostgreSQL, MySQL/MariaDB, MongoDB, Redis or ClickHouse service | Host, port, database, grants and TLS |
| SSH server | A database reachable through a server or bastion | SSH identity, host verification and database destination |
| Discovered container | A supported database found during a server scan | Container identity, local client access and database credentials |
| SQLite file | An allowed local file or supported remote file connection | Host file access, path policy and read-only behavior |
Direct database connection
Open Sources, choose the database type and enter its connection settings. Use a dedicated account restricted to the required schemas and tables. Test the connection before saving or browsing its schema.
Connection success verifies reachability and authentication. It does not prove that an account has appropriate production privileges or that an expensive query is safe. Review source safety.
Reuse an SSH server
Add the server once, then scan for database services. Choose a discovered service to browse databases or configure a single database. The database connection reuses the saved SSH access.
Use database login supplies database credentials independently of the SSH login. When supported, using the server's existing database access opens a local session through that server or container. This needs the database client and a usable authentication path there; an SSH login alone does not establish database authorization.
If a local database session cannot open, confirm that the database CLI is available in the selected host/container and that the SSH identity can use it. Otherwise use a dedicated database login. Do not change a production server's authentication settings simply to bypass a connection error.
Configure a read replica
In source settings, choose Read destination → Read replica and configure the existing replica's connection. This routes ordinary reads to that target and preserves the primary for authorized writes. Errors do not silently send reads back to the primary.
For MongoDB, a saved read replica uses secondary selection for queries, schema discovery and source statistics. It discovers replica-set members even if the supplied URI requests a direct connection; the seed address can change roles. All discovered members must be reachable from the BytesMap host or its configured proxy. If no eligible secondary is available, the read fails instead of falling back to the primary. URI tags and staleness limits still apply.
An ordinary MongoDB connection honors an explicit URI readPreference. Without one, it uses secondaryPreferred, which can read from the primary. Use the saved read replica setting when primary fallback is unacceptable.
BytesMap does not create replicas or measure their lag. Keep schema compatibility and replication health under your database operations process.
Validate the first read
Inspect the schema, choose a small bounded query, and verify its columns and rows. Missing permission, an unavailable server and an empty query result are different conditions; correct the actual cause before building dependent views.
Saved credentials are scoped and encrypted by the host. Credentials should not appear in chart titles, URL inputs, native query literals or exported definitions.