These breaking changes are rolling out on October 15, 2024 and affects only organizations on the Enterprise plan that have implemented project permissions with members assigned the Developer role.

Supabase launched new granular access control for Enterprise organizations so that its members are given access to specific projects instead of the entire organization. You can check out our Launch Week 12 announcement to learn more.

We recently re-evaluated the access that the Developer role has and decided to implement changes to restrict them on a couple of resources to improve your project's security.

On October 15, 2024, we will turn off certain access that the Developer role currently has to your project's resources. The following table is to illustrate all of the breaking changes that will be going into effect:

You can learn more about our Platform Access Control here: https://supabase.com/docs/guides/platform/access-control.

If you have any questions or concerns please contact support.

Deployment of up to 5 read replicas now supported on larger compute sizes#

Previously, each project could only deploy up to 2 read replicas, but we're now raising this limit to 5 for projects on larger compute sizes (XL and above).

PR: https://github.com/supabase/supabase/pull/29250

Link: https://supabase.com/dashboard/project/_/settings/infrastructure

Catch queries that contains an update query without a where clause in SQL Editor#

Another effort to safeguard against running queries with unintended side effects - this time, we're checking for UPDATE queries without a WHERE clause - this check kicks in prior to running the query. We've also consolidated this warning with our existing warning against destructive operations to catch both cases if they exist in the same query.

PR: https://github.com/supabase/supabase/pull/28458

Link: https://supabase.com/dashboard/project/_/sql

Other bug fixes and improvements#

General

• Support querying a table via CMDK by opening the SQL editor (PR)
• Update Supabase Assistant with GPT 4o from 3.5 (PR)

Table Editor

• Improve pagination input field, by only navigating to page on Enter (PR)

SQL Editor

• Fix inability to share queries that are under favorites (PR)
• Fix moving snippets into folders (PR)

Storage Explorer

• Fix to prevent continuously retrying when a file of an invalid mime type is uploaded (PR)

Auth

• Support searching by UID (PR)
• Add confirmation modal when closing tab with unsaved changes on templates page (PR)
• Support adding/removing multiple redirect URLs (PR)

Database

• Fix index page crashing when creating an index on a table with no columns (PR)

Logs Explorer

• Layout shift and scroll fixes (PR)
• Prevent use of WITH, ILIKE or wildcards (PR)

The initial launch of Read Replicas allowed for up to two Read Replicas per project.

The limit for projects on XL compute add-ons and larger has now been raised to 5 Read Replicas per project.

Projects on compute add-ons smaller than XL are still allowed up to 2 Read Replicas per project.

As our user base has grown, we are taking steps to make sure we are able to continue to provide a safe, secure, robust free plan experience. To ensure that email-based auth continues to work for all users on Supabase, we're making changes if you're using the default email provider. This allows us to continue to offer our default provider in a more sustainable and resilient manner.

For maximum flexibility and control over your auth emails, we suggest one of the following:

• Use a custom SMTP provider instead
• Send emails through your own email provider using the email send hook

If you still want to use the default email provider, these are the changes being planned:

• Email template customization will be allowed and customized email templates will not be reverted to default.

• 26th September: If you do not have a custom SMTP server set up, emails can only be sent to email addresses in your project's organization. So for example, if your organization has the following members: person-a@example.com, person-b@example.com and person-c@example.com , this means that email messages from Auth will only be sent to these addresses.

These measures are taken to prevent abuse to our shared SMTP service. In the future, we may consider increasing the email rate limits once we see a drop in abuse.

Frequently asked questions#

Why such a short notice?#

Supabase uses a third-party email sending provider that has mandated we reduce email abuse significantly or they will be forced to block all email sending. A tragedy of the commons.

Can't Supabase switch to a different email sending partner?#

Yes, but we would run into the same issues. All email sending services are required to monitor abuse and force their customers to follow the same rules.

Can't Supabase send emails on their own, without a third party?#

Not really. You can't just send email on the web today without investing a lot of money and time (unblocking port 25, keeping IP addresses out of spam lists, etc.). This is not our core competency and do not have plans to start doing this today.

How long does it take to set up a custom SMTP provider?#

Fortunately this is very easy. You can use any email sending service for this, really popular ones include:

• Resend
• AWS SES
• Postmark
• SendGrid
• Zepto Mail
• Brevo

All you need to do is create an account, verify your sending domain and finally input the SMTP username and password in the Auth settings page.

What if I turn off email confirmations, can I use it then?#

Currently this behavior is not supported and we'll be rolling out a fix for it during the first week of October.

Confirming email addresses is where most of the email message activity for a project originates. Turning it off can be a viable option for some projects that are still in the early testing, development or experimental phase.

Be aware that even if you turn off email confirmations the forgot password or reset password flows in your app continue to function. They also send messages, and starting 26th September those messages will be delivered only to the members of the Supabase organization that owns the project. All other end-users will get a message similar to "Email address not authorized." Effectively, the forgot password / reset password flow will be broken for your project.

What if I want just username + password authentication and using <username>@<fakedomain> instead?#

Please don't do this. Part of the reason why we were forced to lock down these changes is bounced emails, probably from use cases like this.

Official username + password support is going to be made available in the coming year, and until then:

• Use a real domain, that you control
• Send emails to that domain, so set up a receiving server

But the best thing to do is:

• Set up a Send Email Auth Hook that does nothing. You don't even need to use a server or an Edge Function. Just define a Postgres function that just does nothing.

I'm using the admin API to generate links, and not really sending using Supabase's default provider. Do I need to do anything?#

All projects using generate link via the admin API without custom SMTP have been patched to allow the behavior. We still strongly urge those customers to set up custom SMTP regardless.

Just because you're mostly using the admin API to generate links to send in custom email messages, doesn't mean that the Auth server is not configured to use Supabase's shared SMTP service. Your Auth API can be called from your frontend at any time, especially in edge cases such as to handle forgot password or other similar flows, which you may not be handling via the admin API.

Therefore we urge all customers that do use the admin API to set up a custom SMTP sending service regardless.

If you are not interested in setting this up, you can instruct the Auth server to ignore all emails (pretend it's sending them) by configuring a Send Email Auth Hook as a Postgres function that does nothing.

How can I disable the warning banner?#

You can disable the warning banner by setting up a custom SMTP provider , or, if your project doesn't use email at all, by disabling the email provider.

Updates#

20th September 2024#

Email template customization will be allowed and customized email templates will not be reverted to default.

Team has decided that restricting email template customization is not viable and a big breaking change. We may need to do go back to this in the future if abuse continues and our other measures like allowing projects to only send messages to authorized email addresses do not improve the situation. We continue to urge all customers regardless of plan that use the default SMTP service for live applications to move to a custom SMTP provider as soon as able.

• 20th September: Email template customization will no longer be possible without setting up a custom SMTP provider. Email templates already customized can still be customized until 24th September.

• 24th September: Projects without a custom SMTP provider will have their custom email templates returned back to the default ones from Supabase. This means that any auth emails sent out from your project will use the default email template.

Supabase kicked off Launch Week 12 in August with a Postgres+AI drop that went viral followed by other exciting announcements throughout the week. Here’s all the juicy highlights you don’t want to miss:

Day 1 - postgres.new: In-browser Postgres with an AI interface#

Supabase launched postgres.new which reimagines interacting with Postgres using a large language model (LLM) all in the browser. Spin up as many databases as you want, and with the help of an AI assistant, generate tables with sample data or import your data, database migrations, embeddings for semantic search and RAG, reports and charts, and so much more.

Website | Blog Post | Video Announcement

Day 2 - Supabase Realtime: Broadcast and Presence Authorization#

Realtime introduced Broadcast and Presence Authorization to give you fine-grain control over which clients are authorized to join private Channels and what type of Broadcast and Presence actions those clients within the Channels can execute. Get started by writing row-level security (RLS) policies to dictate, as an example, that Client1 can only send messages while Client2 can only receives messages when they’re both in the same private Channel.

Docs | Blog Post | Video Announcement

Day 3 - Supabase Auth: Bring-your-own Auth0, Cognito, or Firebase#

As much as we want you to migrate over to Supabase Auth, we’re not hurt if you want to stay with your current auth provider. I’m sure you have your reasons. That’s why we’ve launched Firebase Auth, Auth0, and Amazon Cognito support so you can bring your auth and it’ll seamlessly work with the rest of Supabase. We’ve also extended multi-factor authentication (MFA) to support both SMS and WhatsApp and introduced Auth Hooks so you can customize your Supabase Auth flow.

Docs | Blog Post | Video Announcement

Day 4 - Introducing Log Drains#

Supabase generates a ton of logs for every product and we provide a Logs Explorer for you to query them. However, we realize that you may want to send them elsewhere for various purposes. We’re not offended; we actually encourage you to do so with the release of Log Drains. You can now send your logs to external destinations like Datadog and via custom HTTP endpoints and we have more destinations in the works like Syslog and Loki.

Docs | Blog Post | Video Announcement

Day 5 - Postgres Foreign Data Wrappers with Wasm#

Supabase Wrappers has released several official Foreign Data Wrappers (FDW), all written in Rust, so you can query data from the likes of S3, Clickhouse, and Stripe. There are many, many data sources out there so we developed WebAssembly (Wasm) support to enable anyone to create FDWs as long as they are familiar with a language that compiles to WebAssembly and can even share their FDWs with the community. Head over to our Catalog to check Official and Community FDWs, including Snowflake and Paddle Wasm Wrappers.

Docs | Blog Post | Video Announcement

One more thing from Launch Week 12#

Just kidding, there’s always more than one. Here’s more goodies we shipped:

• Official Supabase extension for VS Code and GitHub Copilot
• pg_replicate - Build Postgres replication applications in Rust
• Snaplet is now open source
• Supabase Book - Learn Supabase by building a multi-tenant platform
• PostgREST 12.2: Prometheus metrics
• vec2pg: Migrate to pgvector from Pinecone and Qdrant
• pg_graphql 1.5.7: pagination and multi-tenancy support
• Introducing New Platform Access Control
• Supabase Python

Quick Product Announcements#

• [Platform] Changes to Supabase API Keys on 7th October 2024 [Changelog]

• [Auth] Asymmetric Keys support on 7th October 2024 [Changelog]

• [Dashboard] Organize SQL snippets into folders in SQL Editor [Changelog]

• [Dashboard] Supabase AI Assistant: Choose which schemas to share with OpenAI [Changelog]

• [Database] Spin up Supabase project via Vercel Marketplace [Docs]

• [Database] Threshold for transitioning projects to physical backups lowered to 15GB [Changelog]

• [Billing] Supabase moves to hourly usage-based billing [Database] [Storage] [Add-ons]

• [Billing] Improved invoices and more timely usage data [Changelog]

Community Highlights#

• Hyperdome - Chatbot application familiarized with HTMX, Hyperscript, tweets, memes, and lore. [Repo]

• DevCanvas - An open-source Codepen alternative [Repo]

• CraftGen - Build useful AI agents to complete tasks on autopilot [Repo]

• mangosqueezy - Affiliate marketing tool [Repo]

• notedown - A self-hostable rich text editor built with Next.js and Supabase [Repo]

• Supabase Real-world Production Example by Egor Gorbachev [Video]

• This RAG AI Agent with n8n + Supabase is the Real Deal [Video]

This is now live! Read the blog post.

Introduction#

We are introducing asymmetric key cryptography to Supabase Auth in Q4 2024 on 7th October 2024. This will be provided as an additional option to the JWT secret currently shown in the JWT settings page.

Why are we doing this?#

Supabase Auth has always been using a symmetric secret (known as the JWT secret) for signing and verifying JWTs. While this is simple and convenient (since the same secret is used for both signing and verifying), it presents the following problems:

1. Extra network request required to verify the user’s JWT with the symmetric secret. Currently, one needs to make a request to Supabase Auth in order to verify the user’s JWT or copy the JWT secret into their environment. While the latter suggestion improves performance, it can result in security implications if the secret is accidentally leaked, which requires all your keys to be rolled.
2. Difficult to roll with zero downtime. Since the symmetric secret cannot be shared publicly, developers need to wrangle with rolling the secret across their environments while ensuring that the new secret is used.

Benefits of using asymmetric keys#

Asymmetric keys rely on public / private key cryptography, which means that the private key is only used for signing, while the public key is only used for verifying. This solves the above problems in the following way:

• Usage of asymmetric key cryptography rather than a shared symmetric secret for signing and verifying JWTs. Since asymmetric keys don’t use a shared secret, there is less risk of the secret being leaked.
• Faster JWT verification times since there’s no need to make a network call to Supabase Auth via getUser() . The public key can be used for verifying the JWT. Note that adding the symmetric secret to your server-side environment to verify the JWT also has the same effect but is potentially less secure since there is an increased risk of the secret being leaked if it is used in multiple applications.
• Zero-downtime key rotation. Public keys can be exposed in a JSON Web Key Set (JWKs) format, which allows any one of them to be used for verification. When the asymmetric key is rotated, we can still keep the previously used public key in the JWKs endpoint to verify existing JWTs. New JWTs will be signed by the new asymmetric key.

These will include the following changes:

• A public JWKs endpoint for retrieving the public JWK to verify JWTs. This will be exposed through the https://<project_ref>.supabase.co/auth/v1/.well-known/jwks.json endpoint. The symmetric secret will not be exposed through this endpoint for security reasons.
• A new method called getClaims() , which handles verifying the JWT and returning the claims in it.
• Ability to download the public keys in different formats through the dashboard (e.g. PEM, JWKs).

Migration to Asymmetric JWTs#

New projects that are created after 1st May 2025 will be created with an RSA asymmetric key by default. Existing projects can choose to start using asymmetric keys by doing the following:

1. Ensure that you are using the new API keys.
2. Update all your clients to use at least supabase-js version x.x.x (the version number will be updated closer to the release date). In this version, we are introducing a new method called getClaims which handles verifying both symmetric and asymmetric JWTs:

   • Example successful response payload for getClaims()

     
     

     _29

     {

     _29

     "data": {

     _29

     "iss": "https://projectref.supabase.co",

     _29

     "sub": "565dafb5-fd66-4274-9c37-f0ff720f5637",

     _29

     "aud": "authenticated",

     _29

     "exp": 1824717902,

     _29

     "iat": 1724717902,

     _29

     "email": "foo@example.com",

     _29

     "phone": "",

     _29

     "app_metadata": {

     _29

     "provider": "email",

     _29

     "providers": ["email"]

     _29

     },

     _29

     "user_metadata": {

     _29

     ...

     _29

     },

     _29

     "role": "authenticated",

     _29

     "aal": "aal1",

     _29

     "amr": [

     _29

     {

     _29

     "method": "oauth",

     _29

     "timestamp": 1724717902

     _29

     }

     _29

     ],

     _29

     "session_id": "479c1cbf-bd52-42d4-894f-1519f39b3241",

     _29

     "is_anonymous": false

     _29

     },

     _29

     "error": null

     _29

     }

     
     

   • Using getClaims() to verify the JWT

     
     

     _13

     import { createClient } from 'supabase/supabase-js'

     _13

     _13

     const supabase = createClient(SUPABASE_URL, SUPABASE_KEY)

     _13

     _13

     // previously, using getUser() requires making an

     _13

     // additional network request to Supabase Auth to verify the JWT

     _13

     //

     _13

     // const { data, error } = await supabase.auth.getUser()

     _13

     _13

     // getClaims() will always return the JWT payload if the JWT is verified

     _13

     // If it's an asymmetric JWT, getClaims() will verify using the JWKs endpoint.

     _13

     // If it's a symmetric JWT, getClaims() calls getUser() to verify the JWT.

     _13

     const { data, error } = await supabase.auth.getClaims(jwks)

     
     
3. Create an asymmetric key through the dashboard. At this point the symmetric JWT moves to a Previously Used state. Existing JWTs signed with the symmetric JWT continue to be valid, but new JWTs are signed via the asymmetric JWT. Note: The UI mockup below is subjected to change and is just meant to illustrate the different possible states of a signing key.

4. After the JWT expiry period, you can safely revoke the “Previously Used” symmetric JWT, since new JWTs will now be signed with the asymmetric key.

Frequently Asked Questions#

• What do I need to do before I can start using asymmetric keys in Supabase Auth?
  • See migration section above for the detailed steps
• Can I create a symmetric key after I create an asymmetric key?
  • Yes. You will still be able to create a new symmetric key under the JWT settings page in the dashboard. New projects will be created with an asymmetric key by default on 1st May 2025.
• Will the private asymmetric key be exposed?
  • No. Only the public keys will be exposed in various formats (e.g. PEM, JWKs) since those are needed for verification.
• Will I be able to bring my own private key?
  • Yes, you can bring your own private key as long as it complies with the key types allowed.
• What key types can I use to create asymmetric JWTs?
  • By default, asymmetric keys will be created with RS256 by default. You can optionally choose to use ECC or Ed25519. ECC keys are more performant, but not as widely supported as RS256. You can also fallback to HS256 (symmetric keys).

We’re changing the way API keys work in Supabase to improve your project’s security and developer experience. Refer to the timetable below for key dates and info on actions you may need to take in the future.

This change starts out as early preview and is opt-in. No action necessary until at least 1st November 2025. We strongly encourage you to give the new API keys a try!

What's the change?#

These are the planned changes for the API keys:

• anon and service_role keys remain available for use.
• A single publishable key with the form sb_publishable_... can be used to replace the anon key.
• You can create multiple secret keys with the form sb_secret_.... You can also choose not to have a secret key if you don’t need one. Secret keys replace the service_role key.
• You can disable and re-enable the anon and service_role keys, as needed during the migration period.

Summarized, there are 4 types of API keys that can now be used with Supabase. This chart should illustrate it better:

Timetable#

Why are we doing this?#

Since the start of Supabase, the JWT-based anon and service_role keys were the right trade-off between simplicity and relative security for your project. Unfortunately they pose some real challenges in live applications, especially around rotation and security best practices.

The main reasons for making this change are:

• Tight coupling between the JWT secret (which itself can be compromised, if you mint your own JWTs) and the anon (low privilege), service_role (high privilege), and authenticated (issued by Supabase Auth) Postgres roles.
• Inability to independently rotate each aspect of the keys, without downtime.
• Inability to roll-back an unnecessary or problematic JWT secret rotation.
• Publishing new versions of mobile applications can take days and often weeks in the app review phase with Apple's App Store and Google's Play Store. A forced rotation can cause weeks of downtime for mobile app users.
• Users may continue using desktop, CLI and mobile apps with very old versions, making rotation impossible without a forced version upgrade.
• JWTs had 10-year expiry duration, giving malicious actors more to work with.
• JWTs were self-referential and full of redundant information not necessary for achieving their primary purpose.
• JWTs are large, hard to parse, verify, and manipulate -- leading to insecure logging or bad security practices.
• They were signed with a symmetric JWT secret, preventing future development of Auth features.

Start using the new API keys#

It’s easy to start using the new API keys. You can opt in in the Supabase dashboard. This will create the default publishable key and a single secret API key.

For the most part, you can substitute the sb_publishable_... and sb_secret_... values anywhere you used the anon and service_role keys respectively. They work roughly the same in terms of permissions and data access.

You can initialize any version of the Supabase Client libraries with the new values without any additional changes, and we don't expect any backward compatibility issues.

Key differences to be aware of#

We've redesigned how the Supabase hosted platform deals with API keys with a few key goals:

• Advanced and enterprise-ready security features
• Zero-downtime rotation
• Solid foundations for the introduction of asymmetric JWT support and other Auth features requiring this

To achieve these, the new API keys have some subtle differences from anon and publishable:

• Permission and access control. Secret keys are hidden by default and need to be individually "revealed." Each event appears in your organization's Audit Log.
• Instant revocation. By deleting a secret key it is instantly revoked.
• Forbidden use in a browser. Using a secret key in a browser is no longer possible and will always fail with HTTP 401 Unauthorized.
• Limitation with Realtime: Connections last 24 hours when there’s no signed in user, or when using a secret key. Sign users in to extend connections indefinitely.
• Limitation with Edge Functions: Edge Functions provide the option --no-verify-jwt which means they can be called without knowing any API key. You will need to apply this option to functions you are protecting without it.
• Use of the Authorization header. It is no longer possible to use a publishable or secret key inside the Authorization header — because they are not a JWT. Instead pass in the user’s JWT, or leave the header empty. For backward compatibility, it is only allowed if the value in the header exactly matches the value in the apikey header.

We believe these limitations are minor and not likely to impact even a single-digit percentage of existing customers. Should you find any additional limitation do not hesitate to bring it up in this discussion or via Supabase Support.

Schema Visualizer nodes are now persisted#

This was yet another request that we've commonly heard from everyone and we're taking a first step to making this happen 😄 Position of the nodes will now be stored within local storage so that you won't have to re-position them each time you land on this page. We've also added a button to help arrange the nodes automatically if that might be preferred!

Note that if you add new tables to the schema however, the node positions will be defaulted to a certain position that may overlap with other nodes - we're definitely looking into how we can make that better so that new nodes can be easily identified (and then shifted around to your liking 🙂)

PR: https://github.com/supabase/supabase/pull/29136

Link: https://supabase.com/dashboard/project/_/schemas

Other improvements and bug fixes#

General

• Minor improvements to layouts and buttons to ensure their visibility on smaller screens (PR)
• Fix project status filter on home page to only show active projects if only the active checkbox is checked (PR)

Table Editor

• Fix client crash when creating an empty table with no columns (PR)
• Fix handling of of large JSON / text fields in the side panel text editor (PR)

SQL Editor

• Add client side validation for query size (max 1MB) (PR)
• Couple of fixes around adding a new folder with the same name as an existing one (PR)

Database

• Update Stripe Wrapper with more tables (PR)
• Remove docs button for database extensions that have no documentation yet (PR)

Supabase Edge Runtime version 1.57 is compatible with Deno 1.45.

Supabase's hosted platform was upgraded to use this release when serving Edge Functions starting last week.

If you're using Supabase CLI for local development latest stable release 1.192.5, it adds compatibility for Deno 1.45.

How do I find which version of Edge Runtime I'm running?#

Supabase CLI (local)#

When you run supabase functions serve, it should show the current version of Edge Runtime used (and its Deno compatibility)

Hosted Platform#

You can check the served_by field in log events to see which Edge Runtime version was used to serve your function.

We try our best to maintain backward compatibility in these upgrades. If you're experiencing any issues, please feel free to make a support request

Upgrade your organization directly from our pricing page#

https://github.com/user-attachments/assets/2262d816-0c69-4c58-a6e2-1ce4868122f2

Users who are logged in will now be able to select and upgrade their organization from the pricing page itself when clicking on the Upgrade to Pro / Team plan buttons. This is mainly to help streamline this process so that users can upgrade their existing organizations, and prevent confusions where users end up creating new paid organizations instead.

PR: https://github.com/supabase/supabase/pull/28942

Link: https://supabase.com/pricing

UI improvements around credit card billing information#

The selected payment method on the billing page is easily missed as you'll need to scroll down before finding it. In particular with outstanding invoices, it may not be obvious that the wrong card (or even expired card) might have been selected as the default. As such we now will

• Indicate which cards are about to expire (within the current month)
• Indicate which cards have expired
• Show the selected payment method, along with a quick link to change it on the invoices page

PR: https://github.com/supabase/supabase/pull/28971

Link: https://supabase.com/dashboard/org/_/billing

Set payment method as default when adding a new payment method#

When adding a new payment method, we have now added a checkbox to set the card as default which is toggled on by default. This should resolve a UX issue whereby customers needed to explicitly set the card as default in a separate manual step after adding it.

PR: https://github.com/supabase/supabase/pull/28921

Link: https://supabase.com/dashboard/org/_/billing

Choose which schemas to share with OpenAI#

This mainly applies to wherever the Supabase AI assistant is present in the dashboard (SQL Editor + RLS policies). You can now choose which schemas to share with OpenAI as opposed to sending information from all schemas in hopes to improve the output quality of the assistant by only sharing relevant information for your prompts to the assistant.

Do keep in mind that you'll need to opt in to sending anonymous data to OpenAI prior to doing this 🙂 You may also verify exactly what data is being sent here as well under "Important information regarding opting in"!

PR: https://github.com/supabase/supabase/pull/28594

Link: https://supabase.com/dashboard/project/_/sql/new

Other improvements and bug fixes#

General

• Show which is the last sign in method used on login page (PR)
• Added 3 new regions to spin up projects from: Ohio, Stockholm, Paris, and Zurich (PR)
• Commands added for cmd+k to search and open snippets in the SQL Editor (PR)
• Support pasting image (via Cmd/Ctrl + v) in the feedback widget (PR)
• Use expanding text area for RLS AI assistant for multi line prompts (PR)

Table Editor

• Save last selected schema, no longer defaults to public schema (PR)
• Set the correct schema in the schema selector when opening a table via URL directly (PR)
• Support exporting table data as SQL seed file (PR)
• Couple of fixes for bugs around composite foreign keys (PR)
• Improve display of estimated row count for the table if the table has > 50k rows, to emphasize that it's an estimated count (PR)
• Spreadsheet import now checks column types from imported spreadsheet (PR)

SQL Editor

• Fix folder name editing where clicking on the input field toggles the folder (PR)
• Support opening cell value via right click into a side panel for a more detailed view (PR)

Auth

• "With check" checkbox is toggled on by default for commands that involve a with check expression (PR)

Storage

• Support searching and sorting buckets (PR)

Logs Explorer

• Support copying cell content via context menu (PR)