5 Tally alternatives to switch to after the data breach

Tally, the form builder that says it powers more than 500,000 teams, started emailing users this week with a notice no SaaS company wants to send. On August 3, someone reached its Metabase instance. Metabase is not where Tally keeps forms or responses. It is the analytics tool the team uses to see how the product is being used, and it was connected to a database holding user email addresses and password hashes.

The attacker got both.

"They didn't reach your forms, or the answers people submitted to them," Tally's notice reads. "Those are stored separately." That separation is the one piece of good news here, and it is a real one: if you run surveys, job applications, or intake forms on Tally, the responses your respondents typed do not appear to be part of this.

Everything else about the incident is a warning about a category of risk most teams do not have on a list anywhere. It has also sent a lot of people searching for Tally alternatives, so this piece covers both: what actually happened, and which form builders are worth moving to if you decide to switch.

The hole was in Metabase, not Tally

Metabase disclosed on August 6 that its Cloud platform had been attacked using a previously unknown vulnerability, and it notified affected customers, including Tally, the same day. Tally shut down access that day. The public disclosure landed on August 7.

The flaw is an unauthenticated SQL injection in Metabase versions 1.58 and above. Metabase has not assigned it a CVE, but its own advisory (GHSA-vwf4-m7j8-wcjf) rates it Critical with a CVSS score of 10.0 and confirms active exploitation in the wild. CEO Sameer Al-Sakran described it in a blog post as a zero-day used against Metabase Cloud.

Unauthenticated means no login. SQL injection into the application database means the attacker can rewrite configuration, read the stored credentials Metabase holds for every database it connects to, and export whatever those connections can see. Metabase's advisory says exactly that.

The practical consequence is worth stating plainly, because it is the part that generalises past this one vendor: a business-intelligence dashboard is not a reporting layer sitting safely beside your production data, it is a second front door to it, with its own login page and usually far less scrutiny. Metabase does not just query your database. It stores the credentials it needs to do so.

Framework, the modular-laptop maker, disclosed a breach from the same campaign.

Four days, start to finish

The timeline is unusually tight for a supply-chain incident, and the numbers are the most useful thing to take from it: first unauthorised access on August 3, vendor notification and shutdown on August 6, public disclosure on August 7 — four days from intrusion to publication. Compare that to the months that typically elapse between a breach and its disclosure and it is a genuinely fast response by both companies.

Speed does not undo the exposure, though. Whoever holds that Tally export now has a list of email addresses belonging to people who build forms, which is a precise targeting list for phishing, and password hashes that can be attacked offline for as long as anyone cares to keep trying.

How much does "hashed" protect you

Tally's notice makes the standard reassurance: "A hash is one-way, so it can't be turned back into your password." That is true as far as it goes, and it is also the sentence every breached company writes, which is why it is worth unpacking rather than accepting.

A hash cannot be reversed. It can be guessed at. An attacker with the hash list takes a candidate password, runs it through the same function, and checks for a match, over and over, on hardware built for exactly that. Whether this works depends almost entirely on two things Tally has not yet stated publicly: which algorithm was used, and whether each password was salted.

That is not a pedantic distinction. A list of unsalted SHA-256 hashes of common passwords falls in minutes on a single consumer GPU, because the attacker can test one candidate against every account at once and because those hashes have already been computed and catalogued. A list of bcrypt, scrypt, or Argon2 hashes with a unique per-user salt is a different problem: the work factor is deliberately tuned to make each guess slow, the salt forces the attacker to attack each account separately, and a genuinely random password stays out of reach for practical purposes.

The first commenter on the Hacker News thread asked Tally which hash it used and whether passwords were salted, and reported no answer at the time of posting. Any company using a modern framework almost certainly has a sensible default here, and the probability strongly favours a slow, salted algorithm. But until it is confirmed, users should behave as though their password is recoverable, because that is the assumption that costs nothing if wrong.

The same commenter asked the sharper question, and nobody has answered it either: why were password hashes reachable from a usage-analytics tool at all? Metabase exists to answer questions like how many forms were created last month. Nothing in that job requires the credentials column to be in scope. A read-only analytics user scoped to exclude the authentication fields would have turned this incident into a much smaller one.

What Tally users should actually do

Tally's own guidance is to change your password, turn on two-factor authentication, and watch for phishing. That is the right list, in that order, with three things worth adding.

Change the password everywhere you reused it, not just on Tally. Offline hash cracking is patient work, and a recovered password is only interesting to an attacker because of the other accounts it opens.

Treat any email referencing your forms with suspicion for the next several months. The attacker knows you are a Tally user and knows your address. A convincing "your form has new responses, sign in to view" message is the obvious next move, and it costs nothing to send.

And if your organisation runs Metabase itself, patch now rather than filing this as someone else's incident. Self-hosted installations are vulnerable too. The fixed releases are 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, and 0.63.5, covering branches 0.58 through 0.63. If you cannot upgrade immediately, Metabase advises blocking access to the /api/session/reset_password endpoint in the meantime. Then revoke active sessions, review API keys and admin accounts for changes you did not make, rotate the credentials for every connected database, and read your query history.

That last step is the one teams skip, and it is the one that tells you whether anything was actually taken.

For Canadian organisations, there may be a reporting obligation

There is a wrinkle here for teams in Canada that is easy to miss, because the instinct is to read this as a story about someone else's security.

If your organisation used Tally to collect personal information in the course of commercial activity, and one of your staff accounts is in the exposed set, then a credential belonging to your organisation has been compromised. Under PIPEDA, organisations must report breaches of security safeguards to the Office of the Privacy Commissioner and notify affected individuals where the breach creates a real risk of significant harm, and must keep a record of every breach regardless of whether it meets that threshold. Alberta, Quebec, and British Columbia layer their own requirements on top.

The assessment here is genuinely fact-specific and this is not legal advice, but the questions are concrete. Whose accounts were on the exposed list. Whether those passwords were reused on systems holding client or employee data. Whether the exposure creates a real risk of significant harm given what those accounts unlock. Even where the answer is no, the record-keeping obligation does not evaporate, and a documented assessment made now is worth considerably more than a reconstruction attempted later.

The best Tally alternatives after the breach

Tally's appeal was always the free tier: unlimited forms and unlimited submissions, no card, no per-response ceiling. That is a genuinely unusual offer, and it is the thing to match first when you look for a replacement, because most form builders meter exactly the number that grows when your form succeeds. Five worth considering, roughly in order of how closely they replace what Tally does.

Makeform

The closest match on the pricing model, and the most different on how you build. Makeform is an AI-native form builder: you describe the form you want in a sentence, and it drafts the questions, the conditional logic, the copy, and the layout, which you then edit. It offers unlimited forms and unlimited submissions on a free tier with no credit card, within fair-usage limits, alongside 30-plus field types. If what kept you on Tally was never paying per response, this is the nearest equivalent, and the generation step removes most of the blank-page work that makes building a long form tedious.

Google Forms

Free, unlimited, and already inside the Workspace account most organisations have. It is the safest institutional choice and the weakest on design and logic. Responses land in Sheets, which is either the whole point or a data-governance problem depending on who at your organisation can open that spreadsheet. Worth noting in this context: choosing Google Forms does not remove third-party analytics risk, it consolidates it into a vendor whose breach surface is simply much better funded.

Typeform

The design benchmark, one question per screen, and the reason a lot of marketing teams tolerate its pricing. Response limits on the lower tiers are the catch and they are strict, which makes it a poor fit for anything high-volume like a public intake form or a support queue. Choose it when completion rate on a short form is worth real money.

Fillout

The closest thing to Tally in feel, with deeper conditional logic, native integrations, and a free tier that is generous without being unlimited. It is the usual recommendation for teams that outgrew Tally's logic but do not want Typeform's bill, and it handles multi-page and calculation-heavy forms well.

Jotform

The oldest and least fashionable option here, and the one with the widest feature surface: payments, HIPAA-eligible plans, approvals, a very large template library. Its free tier is capped at a low monthly submission count, so it fits regulated or workflow-heavy use cases rather than high-volume public forms.

Should you actually switch

Here is the part most "Tally alternatives" lists will not tell you: switching vendors on the strength of this incident alone gets the lesson backwards, and it is worth being honest about why.

Tally was not careless with passwords. It hashed them, it kept form responses in a separate store, and that separation held. It was breached through a third-party analytics tool that had legitimate read access to a production database, via a flaw nobody knew existed until it was already being exploited. Every form builder on that list of alternatives also runs analytics on its own usage data, and almost none of them publish what tool they use or what it can reach. Moving from one to another changes whose Metabase instance you are trusting, not whether you are trusting one.

The more useful question, for anyone running a SaaS product rather than merely using one, is the inventory question: which internal tools hold live credentials to your production databases, what can each of them read, and when did anyone last check? Read-only dashboards, ETL connectors, error trackers with query logging, AI agents wired into a data warehouse — all of them are copies of your attack surface that rarely appear in a threat model, because they were installed to answer a business question rather than to serve users.

Tally's respondent data survived this because someone had already decided form submissions belonged in a different database from user accounts. That decision was made before the breach, not during it. It is the only kind of decision that helps.

Sources

• Tally customer breach notification, reproduced on Hacker News, August 7, 2026
• Metabase security advisory GHSA-vwf4-m7j8-wcjf and security update blog post
• BleepingComputer, "Metabase SQLi zero-day exploited in customer data-theft attacks", August 7, 2026