QuestDB

QuestDB is an open-source, high-performance time-series database designed for fast ingest and SQL-based analytics. It is wire-compatible with PostgreSQL.

Omnata uses the PostgreSQL wire protocol to replicate data from your QuestDB source database and loads it into Snowflake at regular intervals, as well as providing direct query capabilities to your QuestDB instance.

Connectivity options

Omnata's Snowflake Native App can connect to your database in three ways:

1. Private connectivity endpoints, or Privatelink

2. Omnata's embedded ngrok tunnels

3. Directly over the internet, if the database network is publicly accessible

1. Snowflake private connectivity endpoints (aka Privatelink)

To use Snowflake private endpoints:

1. You must have Snowflake Business Critical Edition

2. Your Snowflake account must be using the same cloud provider as the one you are connecting to. For example, to connect to an AWS Database instance via Privatelink, your Snowflake account must be on AWS.

3. Snowflake supports AWS, Azure and GCP.

2. Omnata-ngrok tunnels

The Omnata tunnelling uses an SSH Tunnel which is provided by our OEM partner ngrok. Omnata establishes a secure TLS tunnel to the ngrok server and then connects to the QuestDB database through a tunnel established from your Snowflake account. This ensures that your database is not exposed to the internet and that your data is secure.

Should I use Privatelink or ngrok?

You will use one or the other, you don't need both. If you have Snowflake Business Critical and the required cloud infrastructure, then we recommend using Privatelink and you won't need ngrok. If you have any other Snowflake Edition, mis-matched cloud providers and/or on-premise data, then ngrok is the best solution for private connectivity.

3. Directly over the internet

The viability of this option depends on your organization's network security policies. Essentially, you must open your network up to incoming traffic from Snowflake's egress IP addresses. Depending on your Snowflake deployment, you will have options to determine the IP range:

• AWS - You can request your account's egress IPs by calling this function.

• Azure, GCP - Egress IPs are not provided by Snowflake and you must open your network to the possible range of the cloud region of your account.

The improvement of this limitation is a Snowflake roadmap item as of May 2026.

Supported Services

• Generic QuestDB (self-hosted)

• QuestDB Cloud

Authentication

User Authentication

Omnata supports QuestDB's standard username/password authentication over the PostgreSQL wire protocol. When you create a connection, you will need to provide the username and password for the QuestDB user you want to use to connect.

QuestDB ships with a default admin / quest user. We recommend creating a dedicated read-only user for Omnata rather than using the default credentials.

Configuration

Privatelink Configuration

If you are using Snowflake Business Critical, you can use Private Link to connect to your QuestDB instance directly from Snowflake. To do this, you will need to ensure you have provisioned a Private Link endpoint (and approved the connection) for your QuestDB instance.

• AWS Private Link

• Azure Private Link

For Privatelink connections, you will need to provide:

• Privatelink Endpoint Domain — the fully qualified name of the Privatelink Endpoint, this must match what was configured in Snowflake

• Port Number — the QuestDB PostgreSQL wire protocol port (default 8812)

• Disable Encryption — optionally disable SSL between client and server (only valid because Privatelink already provides a private network path)

ngrok Tunnel Configuration

If you choose Omnata-ngrok tunnel as the connectivity method, the Omnata UI will guide you through the steps to establish a secure tunnel to your QuestDB instance using ngrok.

Follow this article to understand the configuration steps.

For ngrok connections, you can optionally tick Disable Encryption to disable SSL between the client and server. This is only valid because ngrok already provides a private, encrypted tunnel.

Direct Connection Configuration

For direct connections, you will need to provide:

• Server Fully Qualified Name — the hostname of your QuestDB instance

• Port Number — the QuestDB PostgreSQL wire protocol port (default 8812)

Inbound Syncs

Omnata connects to your QuestDB database via the PostgreSQL wire protocol. Omnata uses the following methods to replicate data from your QuestDB source:

• Incremental (using QuestDB's designated timestamp)

• Full Refresh

Stream discovery

When you configure an inbound sync, Omnata queries QuestDB's tables() and table_columns() system functions to discover the available streams (tables). For each table, Omnata will:

• Use the table's designated timestamp column as the default cursor field. Tables without a designated timestamp can only be synced using Full Refresh.

• Use any columns marked as upsertKey in QuestDB as the primary key. Composite primary keys are supported.

• Build a JSON schema from the column types reported by QuestDB.

Sync strategies

Incremental (Designated Timestamp)

For tables with a designated timestamp, Omnata performs incremental syncs by tracking the maximum cursor value seen on the previous run and only retrieving records with cursor values greater than that watermark.

Full Refresh

For tables without a designated timestamp, or where you explicitly want to re-pull all history, Omnata performs a Full Refresh. This re-reads the entire table on each run.

Data type mapping

Omnata maps QuestDB column types to Snowflake-compatible JSON Schema types as follows:

QuestDB type	Mapped type	Notes
boolean	boolean
byte, short, int, long	integer
long256	string	Stored as string; would require NUMBER(77,0) to represent natively.
decimal(p,s)	number	Precision and scale preserved for Snowflake.
float, double	double
date	string (date-time)	Cast to TIMESTAMP_NTZ(3) in Snowflake.
timestamp	string (date-time)	Cast to TIMESTAMP_NTZ(6) in Snowflake.
timestamp_ns	string (date-time)	Cast to TIMESTAMP_NTZ(9) in Snowflake. See note on precision below.
char, varchar, string, symbol	string
binary	string	Decoded with HEX_DECODE_BINARY in Snowflake.
uuid	string (uuid)
ipv4, geography, interval	string
Arrays (e.g. double[]), geohashes	string	Stored as strings.

A note on timestamp precision

QuestDB's timestamp_ns type stores values at nanosecond precision, while Snowflake's TIMESTAMP_NTZ stores values at microsecond precision in practice. Although Omnata casts timestamp_ns values to TIMESTAMP_NTZ(9) on load, the trailing nanosecond digits are truncated to microseconds during conversion. If sub-microsecond precision is important to your downstream use case, retain the original RECORD_DATA JSON object — the source value is preserved there as a string before the cast.

Managing performance

The following should be viewed as general guidance. Each QuestDB instance is unique in its setup — CPU, memory, disk and network all play a part in how much load can be placed on the server.

Tuning parameters

The QuestDB plugin exposes the following tuning parameters under the Tuning section of the inbound sync configuration. These can be changed without triggering change management workflows.

Parameter	Default	Range	Description
Data reload window minutes	5	0 – 1440	How far the cursor steps back at the start of each run, to catch out-of-order data.
Maximum Concurrent Streams	8	1 – 64	The maximum number of streams (tables) the plugin will process concurrently.
Maximum Records Per Query	1,000,000	50,000 – 5,000,000	The maximum number of records retrieved from QuestDB in a single query. Larger windows are split into smaller chunks.
Query retry count	3	1 – 20	The number of times a query will be retried to work around transient network errors between Snowflake and QuestDB.

Initial load considerations

When you run a sync for the first time, the plugin requests all historical data for the selected streams, which is when the heaviest load will be placed on your QuestDB instance. Subsequent runs only fetch new records (plus the reload window), which is a much lighter touch.

For very large initial loads, consider:

• Reducing Maximum Concurrent Streams to limit the number of tables being read in parallel.

• Reducing Maximum Records Per Query to keep individual query memory footprint smaller on the QuestDB side.

• Temporarily setting the Snowflake warehouse to multi-cluster to reduce queueing while large volumes are being processed.

Outbound Syncs

Outbound syncs to QuestDB are not currently supported. Contact us if this is a use case you'd like to discuss.

Functions

To enable you to query your QuestDB instance directly from Snowflake, the plugin provides a UDF in the OMNATA_QUESTDB_PLUGIN.UDFS schema.

SQL_QUERY

Executes a SQL query on the source QuestDB instance and returns the result as a single-column table of objects.

Parameters:

• CONNECTION_PARAMETERS (OBJECT): The connection object for the QuestDB connection

• QUERY (VARCHAR): The SQL query to execute

Example:

select *
from table(OMNATA_QUESTDB_PLUGIN.UDFS.SQL_QUERY(
    <connection_parameters>,
    'select * from trades where timestamp > dateadd(''h'', -1, now())'
));