GitHub's archive banner, not Vanna itself, signals the project is frozen

Start with what actually decays. The SQL generation logic does not rot; pinned MIT code keeps doing on any given Tuesday exactly what it did on 2 February 2026 ^[3][11]. What moves is everything the library touches: a database driver cutting a new major version, a model provider changing its API ^[12]. That is the failure mode you are now underwriting yourself, because a read-only repository can neither accept a new issue nor merge a pull request ^[5].

The maintenance arithmetic is worth being precise about. There were 289 open issues and pull requests on 30 August 2026, 227 of them issues ^[4], which leaves 62 open pull requests ^[13] that will never land. None of them will land in a fork either, at least not visibly: the highest-starred of the 2,491 forks had 4 stars on 30 August 2026 ^[7][6], and nothing anywhere in the 24-repository vanna-ai organisation has been pushed since 14 February 2026 ^[8]. Two thousand four hundred and ninety-one forks and no maintenance candidate among them is the clearest signal in the whole dataset.

The README itself undercuts every other write-up on this. Intellrise says it swept the full 9,578-byte file on 30 August 2026 for archived, no longer maintained, maintenance mode, deprecated, read-only and successor, and got zero matches; it still opens with "Vanna 2.0: Turn Questions into Data Insights" and still carries an Enterprise Support section 281 lines in ^[9]. The archive banner is generated by GitHub, not written by the project ^[10]. So the canonical document a new engineer reads, and the document a model was trained on, both describe a maintained project. Your onboarding path will keep recruiting people onto a frozen dependency until somebody edits your own docs.

Note also that the product is still sold. vanna.ai returned HTTP 200 on 30 August 2026 and the pricing page still listed Explorer at $50/mo for 20 questions/day, Team at $500/mo for 300 questions/day, and Enterprise custom with unlimited questions ^[14][15]. Those daily caps function as an architectural constraint: 300 questions/day across a team is 12.5 an hour ^[16], which is fine for analysts and not fine for an agent in a loop. According to the same write-up, the archive says nothing about the cloud service ending ^[17].

One caveat on sourcing. This account comes from Intellrise, which sells a competing product and discloses that up front ^[18]. The load-bearing items are checkable against GitHub directly: archived: true, the 2 February push, the star and fork counts ^[2][3][6][7]. Check them before you write the migration ticket, not after.

The honest posture is a pin plus a documented exit. Pin the version, pin the driver majors it works against, and write down which model provider endpoint you depend on, because that is where the break arrives first ^[12]. A wait-and-see stance is only viable while nobody upstream ships a breaking change, and you do not control that schedule.