Thanks for raising this question. I recently evaluated similar options for Snowflake-to-Databricks ingestion and would like to share my perspective.

From my understanding, the choice depends on whether your primary focus is performance, ease of management, or long-term architecture.

1. Is the Snowflake Spark Connector still supported and recommended?

Yes, the Snowflake Spark Connector is still actively supported by Snowflake and remains one of the most commonly used approaches for moving data between Snowflake and Spark-based platforms, including Databricks.

I believe the Databricks documentation you referenced is primarily referring to legacy query federation guidance rather than the Snowflake Spark Connector itself.

Snowflake continues to maintain and document the connector:

Snowflake Connector for Spark:
https://docs.snowflake.com/en/user-guide/spark-connector

Databricks also provides guidance on reading and writing Snowflake data:
https://docs.databricks.com/aws/en/archive/connectors/snowflake

2. Snowflake Spark Connector vs JDBC

For large-scale ingestion workloads, I would generally prefer the Snowflake Spark Connector over JDBC because:

• Better parallelism for data movement

• Query pushdown support

• Higher throughput for larger datasets

• Optimized integration with Spark workloads

JDBC works well for:

• Smaller datasets

• Metadata queries

• Administrative operations

• Simpler integrations where performance is not a primary concern

For custom-query-based ingestion specifically, the Snowflake Spark Connector supports executing custom SQL while still benefiting from connector optimizations.

3. Any limitations with the Snowflake Spark Connector?

A few areas to consider:

• Connector version compatibility with Spark/Scala runtime versions

• Dependency management

• Network connectivity and security configuration between Snowflake and Databricks

• Additional operational overhead compared to fully managed ingestion solutions

That said, many production implementations continue to use the connector successfully for high-volume ingestion.

4. What would I recommend for the long term?

If I were designing a new solution today, I would consider:

Short to Medium Term
Snowflake → Snowflake Spark Connector → Databricks Delta Tables

Long Term
Evaluate Lakeflow Connect as it matures and reaches GA, since Databricks is clearly investing in managed ingestion and replication capabilities.

Lakeflow Connect documentation:
https://docs.databricks.com/en/ingestion/lakeflow-connect/index.html

My Personal Take

For a production-grade ingestion framework that requires custom SQL extraction and high-volume data movement, I would currently choose the Snowflake Spark Connector over JDBC.

JDBC is certainly a viable option, but in most cases I would view it as a simpler connectivity mechanism rather than the preferred approach for large-scale ingestion workloads.

Would be interested to hear from others who have recently compared Snowflake Spark Connector, JDBC, and Lakeflow Connect in production environments.