FalkorDB Snowflake Native App Demo

This demo simulates a user (consumer) of Snowflake that has tables with data, and a FalkorDB app published into the Snowflake marketplace with staging folder that can accept data from the consumer.

How to Start the Demo

Follow these 3 steps in order to set up the complete demo:

Step 1: Setup Consumer

Set up the consumer database, schema, tables, and load initial CSV data:

./scripts/setup_consumer.sh

Step 2: Setup App

Set up application infrastructure, build/push Docker image, and publish the app package:

./scripts/setup_app.sh

Step 3: Instantiate App

Create an app instance and configure staging connections:

./scripts/instansiate_app.sh

How to Run the Demo (day to day)

After the one-time setup above, there are just two scripts:

./scripts/demo_up.sh      # start everything and load the full demo
./scripts/demo_down.sh    # stop everything so nothing bills

demo_up.sh does the whole thing in one command: starts the compute pool, warehouse and service, waits until the service is READY, uploads the Air Routes CSVs (examples/airroutes, ~48k airports and ~67k routes) into Snowflake, creates the graph indexes before loading any data, binds each table to the app with register_callback + SYSTEM$REFERENCE (no Permissions UI needed), loads the airports and routes, computes route distances, and prints the FalkorDB Browser URL.

demo_down.sh suspends the service and the compute pool. This matters: the pool bills per node-hour for as long as it is active and nothing suspends it automatically — the FalkorDB service is a long-running container, so the pool is never idle and AUTO_SUSPEND_SECS never fires.

Both are safe to re-run. Useful flags:

./scripts/demo_up.sh --skip-upload   # rebuild the graph, reuse the Snowflake tables
./scripts/demo_up.sh --no-data       # start the service only
./scripts/demo_down.sh --drop        # drop the service instead of suspending it

Data is reloaded on every start because graph data is not persisted (the service mounts a stage for CSV staging only).

Defaults can be overridden with environment variables: FALKORDB_APP_NAME, FALKORDB_ROLE, FALKORDB_POOL, FALKORDB_WAREHOUSE, FALKORDB_DEMO_DB, FALKORDB_SNOW_CONNECTION.

Use demo_down.sh between demos, and the teardown scripts below only when you want to remove the environment entirely.

How to Use the Demo

Once the demo is running, you can call the FalkorDB app procedure:

# Call the load_csv procedure as specified in architecture
# load_csv(graph, table, cypher_query) that:
# 1. loads data from table to staging area with the name table.csv
# 2. calls the service function load_csv(graph, table.csv, cypher_query) 
# 3. keeps the result, deletes table.csv from staging and returns the result

# Example usage:
snow sql -q "
USE APPLICATION falkordb_app_instance;
CALL app_public.load_csv('social_graph', 'social_nodes', 'CREATE (:Person {name: \$name, label: \$node_label})');
"

You can also call other procedures:

curl -X 'GET' \
  'http://localhost:8080/list_graphs' \
  -H 'accept: application/json'

How to Stop the Demo

Quick Teardown (All Steps)

Run the complete teardown in one command:

./scripts/teardown.sh

Manual Teardown (Step by Step)

Or follow these 3 steps in reverse order to clean up the demo:

Step 1: Uninstantiate App

Remove the app instance and clean up instantiation:

./scripts/uninstansiate_app.sh

Step 2: Teardown App

Remove the application package and infrastructure:

./scripts/teardown_app.sh  

Step 3: Teardown Consumer

Remove the consumer database and related resources:

./scripts/teardown_consumer.sh

View Container Logs

To view container logs while the demo is running:

./scripts/logs.sh

Architecture

This demo follows the architecture specified in architecture.md with exactly 3 setup scripts and 3 teardown scripts, implementing the staging workflow where the consumer calls load_csv(graph, table, cypher_query) to process data through the FalkorDB app.