Skip to content
SPSync SPSync SPSync Docs
Back to spsync.io

Destination setup guides

Each guide below follows the same order: what to install, how to create the database and a user that can only do what SPSync needs, how to let SPSync reach it, how to encrypt the connection, which sign-in methods work today, how to connect from the desktop app, the CLI or an AI assistant, what the connection test proves, and the errors people hit.

Relational destinations

Section titled “Relational destinations”
  • SQL Server: on-premises, an Azure virtual machine, Azure Arc-enabled SQL Server, and Amazon RDS for SQL Server.
  • Azure SQL: Azure SQL Database and Azure SQL Managed Instance.
  • PostgreSQL: self-hosted, Azure Database for PostgreSQL, Supabase, Neon, Amazon RDS and Aurora, Google Cloud SQL and AlloyDB, and Heroku Postgres.
  • MySQL and MariaDB: self-hosted, Azure Database for MySQL, Amazon RDS and Aurora, and Google Cloud SQL.
  • Oracle Database: including the two-schema requirement.
  • SQLite: one local file, no server.
  • DuckDB and MotherDuck: one local file or a MotherDuck database, plus the Parquet export.

Warehouse and lake destinations

Section titled “Warehouse and lake destinations”
  • Google BigQuery: a dataset and a service account with two roles.
  • Databricks: Unity Catalog grants, the SQL warehouse HTTP path, and a personal access token or OAuth service principal.
  • ClickHouse: ClickHouse Cloud and self-hosted, the two ports, and secure=1.
  • Azure Data Lake Storage Gen2: Parquet files in a container, with a SAS token or an Entra identity.
  • Delta Lake: Delta tables on local disk, Amazon S3 or Azure storage.
  • Apache Iceberg: tables through a REST catalog.
  • Microsoft Dataverse: an Entra app registered as an application user.

Search and vector destinations

Section titled “Search and vector destinations”
  • Elasticsearch: an API key or user, https, and Elastic Cloud traffic filters.
  • OpenSearch: a security-plugin role, a VPC domain, and AWS request signing.
  • Azure AI Search: the admin key, index names and an optional vector field.
  • PostgreSQL with pgvector: the extension, PostgreSQL 15 and embedding providers.
  • Qdrant: self-hosted or Qdrant Cloud, with an API key.
  • Weaviate: the REST and gRPC ports.
  • LanceDB: a local folder or an object store.

What every guide shares

Section titled “What every guide shares”

Relational and ClickHouse destinations take a username and password in a connection string. SPSync never writes that string to the replication config: the config names an environment variable that holds it. Warehouse and lake destinations use a service-account key (BigQuery), a token or service principal (Databricks), a SAS token or Entra identity (Azure storage), storage keys (Delta Lake on S3) or a client secret (Dataverse), and each guide says which. Microsoft Entra ID sign-in and cloud IAM database tokens are not supported for any relational destination today.

The search and vector destinations take an API key (Elasticsearch, OpenSearch, Azure AI Search, Qdrant and Weaviate) or a user name and password (Elasticsearch and OpenSearch). They keep a small local state file to send only changed rows, and the config names an environment variable for the key as well. pgvector takes a PostgreSQL connection string, and LanceDB takes a folder or an object-store location.