At Cloud Next, we’ve announced Realtime PostgreSQL, Native SQL support, custom resolvers, and more.

Firebase Data Connect started with a simple goal: bring the Firebase developer experience to relational databases. Our initial focus was to help build secure, scalable apps backed by PostgreSQL. Thus we leveraged a declarative GraphQL syntax to provide strict type-safety and built-in security.

To truly deliver on the promise of bringing SQL to Firebase, we’ve spent the last year rapidly expanding what the platform can do. We have brought the reactive, real-time magic that Firebase is known for, deepened our SQL support by allowing you to use raw SQL alongside GraphQL, and introduced the kind of low-friction experience that defines Firebase: getting started without pulling out a credit card.

To reflect this evolution, Firebase Data Connect is officially becoming Firebase SQL Connect. It’s the same scalable architecture, but with a renewed focus on unlocking the full potential of Postgres.

Let’s dive into everything new.

Realtime and Offline Caching

Realtime Query Updates has been the #1 requested feature on Firebase UserVoice, and for good reason: modern apps rely on reactive data.

Instead of writing complex reverse query matching logic from scratch, SQL Connect now allows you to subscribe to queries and push updates to clients whenever the query result changes. You define this behavior using the new @refresh directive in your operation files.

You can configure queries to refresh on a time interval, or bind them directly to mutation executions using a CEL-expression:

# Refresh this query whenever the authenticated user updates their profile
query UserProfile
@auth(level: USER)
@refresh(
  onMutationExecuted: {
    operation: "UpdateUser"
    condition: "mutation.auth.uid == query.auth.uid"
  }
) {
  user(id_expr: "auth.uid") {
    id
    name
  }
}

By letting you to check multiple conditions—like matching IDs and evaluating specific field flags—CEL bindings give you fine-grained control over your database reads. Dive into our documentation to explore all the advanced real-time patterns.

Offline Caching

Alongside realtime updates, we are also launching Offline Caching (your #4 most requested feature). The SQL Connect SDKs now natively support query-level and entity-level caching. Your app will instantly show cached views while waiting for backend responses, ensuring a consistent and snappy UI even when internet access drops. You can easily configure your client cache settings—like max age, size limits, and storage type—directly in your connector.yaml file:

connectorId: friendly-app
generate:
  javascriptSdk:
    outputDir: app/dataconnect-generated
    package: "@dataconnect/generated"
    clientCache:
      maxAge: 10s
      maxSize: 300MB
      storage: memory

Check out the docs for more details!

Lower pricing & No-cost trials

Building a quick prototype, testing a schema, or scaling a hit app shouldn’t require navigating complex billing setups or worrying about surprise charges. We’re excited to highlight 2 major pricing updates to help you build with SQL Connect for less.

No-cost trials

You can now spin up a PostgreSQL database instance at no cost for 90 days on the free Spark plan—no credit card required. The trial provisions an instance equivalent to a db-f1-micro (1 vCPU, 10 GB SSD), which gives you plenty of room to prototype. If you are on the pay-as-you-go Blaze plan, you qualify for a 3-month free trial with unlocked configuration controls, allowing you to add read replicas or private IPs as needed.

Price drop for operations

New efficiencies while building real time have let us operate at a lower cost – and we wanted to pass those savings to you. Starting May 1st, SQL Connect is now priced from $0.90 per million operations! This new rate includes all operations, from real time subscriptions to your most complex Native SQL mutations. Have an operation that updates 8 tables in a single transaction? That’s still one operation. Plus, if you’re on the blaze plan, you still get 250,000 free operations per month.

For more information, check out our documentations and blog.

Or better yet, get started and start bashing!

Native SQL

While SQL Connect’s declarative GraphQL syntax provides great type safety for standard CRUD operations, there are times when you really want the flexibility of SQL. When you hit advanced use cases—like window functions, geospatial indexing, or complex atomic operations—shoehorning these into GraphQL types becomes much more difficult.

Native SQL lets you bypass the auto-generated queries and provide raw SQL commands directly into your .gql operation files. Because these statements are validated at deploy-time and strictly parameterized by the server, you get the exact execution you want without having to worry about SQL injections.

For example, you can now directly invoke Postgres spatial extensions like PostGIS to query geographic coordinates, such as finding trending tags within a specific radius of a user:

# Finds trending tags within a certain radius using PostGIS geographic functions
query GetTrendingNearMe(
  $userLng: Float!
  $userLat: Float!
  $radiusMeters: Float!
) {
  regionalTrends: _select(
    sql: """
    SELECT
      t.name
    FROM tag t
    JOIN post_ownership po ON po.tag_id = t.id
    JOIN "user" u ON u.id = po.user_id
    WHERE po.tags > 0
      AND ST_DWithin(
        ST_MakePoint(u.longitude, u.latitude)::geography,
        ST_MakePoint($1, $2)::geography,
        $3
      )
    """
    params: [-80.5012, 43.4503, 50000]
  )
}

Read more to learn when to use views vs and Native SQL, or how to use it in your app.

Custom Resolvers (experimental)

Native SQL covers your complex Postgres needs, but what if your data doesn’t live in Cloud SQL?

For scenarios where you need to integrate external APIs (like Stripe or X), access Cloud Storage, or query another data source like BigQuery, we are introducing Custom Resolvers. By writing custom resolvers backed by Cloud Functions for Firebase, you can extend SQL Connect to combine multiple data sources into a single, unified mutation. This allows you to apply custom business logic and maintain a single authorization layer for your entire backend, while still generating type-safe client SDKs.

For example, the following snippet fetches a user’s X (Twitter) post to verify it contains a specific hashtag. Once validated, it triggers a Native SQL database transaction based on that external data:

resolvers: {
    mutation: {
      // Each resolver is defined individually
      async boostFromTweet(
        _parent: unknown,
        args: Record<string, unknown>,
        _contextValue: FirebaseContext,
        _info: unknown,
      ) {
        const tweetUrl = args.tweetUrl as string;
        const userId = args.userId as string;
        // Extracting data from external source
        const response = await fetch(
            `https://api.x.com/2/tweets/${tweetId}`,
            {
              headers: { Authorization: `Bearer ${XToken.value()}` },
            },
          );
         const text = json.data.text;
	   // Custom logic depending on your use case
          if (!text.toLowerCase().includes("#firebasesqlconnect")) {
            return {
              success: false,
              message: "Missing #FirebaseSQLConnect tag.",
            };
          }

          const symbol = extractEmoji(text);
          // Execute a Native SQL transaction using the validated external data
          const transactionResult = await executeReadXPostTransaction({
            symbol: symbol,
            boostAmount: boostAmount,
            tweetId: tweetId,
            userId: userId
          });
	   // Return formatted results to the generated client SDK
          const rows = transactionResult.data?.readXPost as any[] | undefined;
          return {
            success: true,
            symbol,
            boostAmount,
            message: "Boost applied!",
          };
        }
      }
}

To see this in action, check out the video of our Cloud Next demo that integrates SQL connect with Big Query through custom resolvers.

Since last year at Next

Everything we’ve introduced builds on a steady foundation of features we’ve shipped since last year’s Next:

• Full-text search: Use lexical stemming to efficiently search across multiple Postgres columns without needing a separate search engine integration. See docs.
• Admin SDKs: Execute bulk data management operations from privileged server environments using type-safe SDKs generated from your schemas. See docs.
• Event Triggers: Automatically kick off server-side workflows (like sending welcome emails or processing images) the moment a SQL Connect mutation is executed. See docs.

It was wonderful seeing you at Next, and we’re back to working hard on even more SQL Connect magic. So don’t forget to drop us a note on Firebase UserVoice with the Data Connect tag!