Configure Destination Database

You can configure SingleStore databases as a destination. To configure the destination database, navigate to Dashboard > Destination, and then select the gear icon.

  1. In the Destination Database dialog, select SingleStore from the Destination Database list.

  2. In the SingleStore tab, enter the following configuration details:

    1. Host Name: Enter the IP address or hostname of the database server.

    2. Port: Enter the port number on which the database server is listening (default port for SingleStore is 3306).

    3. User ID: Enter a valid SingleStore user ID to be used with Ingest.

    4. Password: Enter the password for the SingleStore user.

      Note: Passwords are encrypted within Ingest.

    5. JDBC Options (Optional): JDBC options are optional and can be used to extend the JDBC URL for accessing the database.

  3. Select the Advanced Options tab. Enter the following configuration details:

    1. Max Updates (Default maximum update is 4): Enter a number that controls when Flow consolidates multiple changes to the same record. When loading data, if the number of sequential changes to the same record exceeds twice this value, Flow groups the changes by primary key before applying them to the destination. Enter -1 to disable consolidation.

    2. Load Threads: Enter the number of parallel loading threads that Flow uses for the destination. Increase this value to allow more concurrent load activity, depending on the capacity of your host and SingleStore deployment.

    3. Add Database Prefix: Enter a prefix to add to the destination schema names. For example, if the prefix is prod and the source table is mydb:sales.customers, the destination becomes prod_mydb_sales.customers. Leave blank to use the original schema names.

    4. Truncate table instead of drop: Enable this to truncate existing destination tables instead of dropping and recreating them. Use this option when you want to reuse the destination table object while replacing its data.

    5. Database name and optional table name pattern: Controls how source tables are mapped to destination database and table names. Supports placeholders:

      %d - source database name

      %s - source schema name

      %t - source table name

      For more information and examples, refer to Destination Naming and Multi-Tenant Support.

    6. Ignore database name in schema: Enable this to exclude the source database name from destination table names. Use this when the source database name is not needed in the destination naming convention.

    7. Database for staging tables: Enter a schema or database name where Flow creates staging tables during the load process. Leave blank to create staging tables in the same location as the destination tables.

    8. Retain staging tables: Enable this to retain staging tables in the destination after loading completes. Enable this option when you want to inspect staging data for troubleshooting or validation.

    9. Sync Struct suppressed: Enable this to prevent Flow from recreating destination tables or applying schema changes when structure mismatches are detected, or when Sync Struct operations are run. When enabled, Flow ignores table structure differences and does not modify destination tables. This is disabled by default. For more information about Sync Struct, refer to Schema Evolution with Sync Struct.

    Refer to Appendix for more information.

  4. Select Apply to confirm and save the details.

  5. Select Test to verify the connectivity.

Destination Naming and Multi-Tenant Support

The Database name and optional table name pattern field in the Advanced Options controls how source tables are written to the destination and supports multi-tenant configurations.

Important

Multi-tenant support is available for MySQL, PostgreSQL, SQL Server, and Oracle sources.

To configure multi-tenant mappings, enter a database name followed by the destination table name in the following format:

<dbname>.<destination_table_name>

The destination_table_name can include the following symbols along with underscores. No other special characters supported :

  • %d: Source database name

  • %s: Source schema name

  • %t: Source table name

Note

For MySQL and Oracle sources, %d is not supported. Use %s to refer to the database name.

Use the following patterns to control how source objects are mapped to the destination:

  • To map all source tables into a single SingleStore database, enter a fixed database name such as main_db.

  • To map multiple source schemas into one SingleStore database, enter a fixed destination database name and include the source schema name in the destination table pattern. For example: dest_db.%s_%t.

  • To map multiple source schemas into multiple databases, include a placeholder in the destination database name so that Flow derives the destination database dynamically from the source schema or database name. For example: main_%s.primary_%t.

Multi-Tenant Examples (PostgreSQL, SQL Server)

Example 1

  • Source database: tenant1_db

  • Source table: customers

  • Database name and optional table name pattern set to: main_db.%d_%t

  • Destination database name: main_db 

  • Destination table: tenant1_db_customers

Example 2

  • Source database: server_db

  • Source schema: org1

  • Source table: supplier

  • Database name and optional table name pattern set to: dest_db.%s_%t

  • Destination database name: dest_db 

  • Destination table: org1_supplier

Multi-Tenant Examples (MySQL, Oracle)

Example 1

  • Source database: org1_db

  • Source table: customers

  • Database name and optional table name pattern set to: dest_db.%s_%t

  • Destination database name: dest_db 

  • Destination table: org1_db_customers

Example 2

  • Source database: vdb

  • Source table: customers

  • Database name and optional table name pattern set to: main_%s.primary_%t

  • Destination database name: main_vdb 

  • Destination table: primary_customers

Last modified:

Was this article helpful?

Verification instructions

Note: You must install cosign to verify the authenticity of the SingleStore file.

Use the following steps to verify the authenticity of singlestoredb-server, singlestoredb-toolbox, singlestoredb-studio, and singlestore-client SingleStore files that have been downloaded.

You may perform the following steps on any computer that can run cosign, such as the main deployment host of the cluster.

  1. (Optional) Run the following command to view the associated signature files.

    curl undefined
  2. Download the signature file from the SingleStore release server.

    • Option 1: Click the Download Signature button next to the SingleStore file.

    • Option 2: Copy and paste the following URL into the address bar of your browser and save the signature file.

    • Option 3: Run the following command to download the signature file.

      curl -O undefined
  3. After the signature file has been downloaded, run the following command to verify the authenticity of the SingleStore file.

    echo -n undefined |
    cosign verify-blob --certificate-oidc-issuer https://oidc.eks.us-east-1.amazonaws.com/id/CCDCDBA1379A5596AB5B2E46DCA385BC \
    --certificate-identity https://kubernetes.io/namespaces/freya-production/serviceaccounts/job-worker \
    --bundle undefined \
    --new-bundle-format -
    Verified OK

Try Out This Notebook to See What’s Possible in SingleStore

Get access to other groundbreaking datasets and engage with our community for expert advice.