# 🌀 Airsequel 0.6 - Teams, Pro Plan, API Access Control, and more!

**URL:** <https://discourse.elm-lang.org/t/airsequel-0-6-teams-pro-plan-api-access-control-and-more/9327>\
**Category:** Show and Tell\
**Created:** [September 15, 2023, 3:19pm UTC](https://discourse.elm-lang.org/t/airsequel-0-6-teams-pro-plan-api-access-control-and-more/9327 "2023-09-15T15:19:31Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![ad-si](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/ad-si/32/4713_2.png) [@ad-si](https://discourse.elm-lang.org/u/ad-si)\
**Post date:** [September 15, 2023, 3:19pm UTC](https://discourse.elm-lang.org/t/airsequel-0-6-teams-pro-plan-api-access-control-and-more/9327/1 "2023-09-15T15:19:31Z")

</div>

This version has been a long time coming and it’s finally online! Welcome to [Airsequel v0.6](https://www.airsequel.com)! 🎉

> I’m posting this here, because our goal is to become the easiest to use backend for Elm apps.  
> Check out the tutorial: [How to build a todo app with Airsequel and Elm](https://docs.airsequel.com/tutorials/how-to-build-a-todo-app-with-airsequel-and-elm)!  
> (Also, our complete frontend is written in Elm.)

Our main goal with this release is to enable professional usage of our hosted version of Airsequel at [airsequel.com](https://www.airsequel.com). Until now every database was standalone and public (unlisted). Now we have:

- Full fledged user and team management
  - Teams own databases
    - Databases are either private or public (unlisted)

  - Existing public databases can be assigned to teams
  - Check out the [documentation](https://docs.airsequel.com/conceptual-overview#users) for more details

- New paid Pro plan with less restrictions than the free plan. Check out the detailed feature comparison at [airsequel.com/pricing](https://airsequel.com/pricing).

- API access tokens for fine grained control on how a database can be accessed via its API

Other notable improvements are:

- Option to create databases from an AI prompt
- Dedicated read-only endpoint to duplicate databases at  
`/readonly/<readonly-id>/duplicate`
- Description field for databases and tables
- GraphQL
  - Add support for comparison operators `like` and `ilike`
  - Support filters over several columns in mutations and queries
  - Support `limit` and `offset` arguments to only show a subset of the result rows
  - Support `order_by` argument in queries
  - Results are no longer reversed

For the full list of all changes check out [our changelog](https://docs.airsequel.com/changelog).

We also have a blog at [blog.airsequel.com](https://blog.airsequel.com/) now. Our latest article about [Exciting SQLite Improvements Since 2020](https://blog.airsequel.com/exciting-sqlite-improvements-since-2020/) was well received on [Hacker News](https://news.ycombinator.com/item?id=35740683).

All those improvements also are available on our Enterprise Edition. You can request an Enterprise trial instance at [airsequel.com/trial](https://airsequel.com/trial).

Last but not least: I hope a few of you might also consider buying a subscription even though you currently don’t have strong incentives to do so. There are not many companies left trying to build a sustainable business powered by Elm and we would be very grateful for any help we can get! We’re also planing to open source parts of our code like the core SQLite to GraphQL engine, and the Elm table component. Any financial support would really help here! 🙇‍♂️

Can’t wait to hear your feedback! 😊

---

<div class="post-metadata">

**Author:** ![supermario](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/supermario/32/92_2.png) [@supermario](https://discourse.elm-lang.org/u/supermario)\
**Post date:** [September 24, 2023, 3:14pm UTC](https://discourse.elm-lang.org/t/airsequel-0-6-teams-pro-plan-api-access-control-and-more/9327/2 "2023-09-24T15:14:08Z")

</div>

Hey @ad-si – love your work! Congratulations on another release.

I was looking around for information on schema changes / migrations, i.e. how I would manage the lifecycle of my data schema over time (i.e. field additions/removals/renaming/type changes).

Are there some docs/concepts on that I missed? Or is that up to the user to manage themselves with SQL directly? If the latter does it have some impact/consideration for the other features like auto GraphQL APIs, spreadsheets, etc?

---

<div class="post-metadata">

**Author:** ![ad-si](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/ad-si/32/4713_2.png) [@ad-si](https://discourse.elm-lang.org/u/ad-si)\
**Post date:** [September 25, 2023, 8:05am UTC](https://discourse.elm-lang.org/t/airsequel-0-6-teams-pro-plan-api-access-control-and-more/9327/3 "2023-09-25T08:05:13Z")

</div>

Thank you! 😊

Right now users must manage it themselves with SQL. As far as I can tell there should be no surprising implications for the API or UI. Airsequel is stateless in the sense that everything is stored in the SQLite database and any changes you apply to the SQLite database are also reflected in the API / UI. (Therefore you can also download the database, modify it locally, and re-upload it without any problems.)  
We should probably add a section about it to the documentation.

However, we’ve been thinking about adding a “Migrations” tab / setting with a dedicated UI to write, list, apply, and revert migrations just to make it easier for users to manage the whole migration life cycle and keep track of it. Do you think that would be a good addition? Do you have any other ideas on how to improve the status quo?

---

<div class="post-metadata">

**Author:** ![supermario](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/supermario/32/92_2.png) [@supermario](https://discourse.elm-lang.org/u/supermario)\
**Post date:** [September 25, 2023, 10:11am UTC](https://discourse.elm-lang.org/t/airsequel-0-6-teams-pro-plan-api-access-control-and-more/9327/4 "2023-09-25T10:11:32Z")

</div>

Okay cool, gotcha.

I was thinking about how a Lamdera + Airsequel demo or use-case might look. I guess you’d have to take the “use discipline to ensure you only ever add fields, and stagger a rename/removal over multiple deploys” approach.

Maybe versioned schemas or something could make things a little better, but it seems that’s not an SQLite thing, and things get pretty complicated quickly with that approach anyway.

The migrations tab thing could be nice but brings more questions than answers for me, personally my main concern is “will this schema still match what my app expects or will I break everything in prod”, so my thinking is about how you could make that clarity as pain-free as possible, even in the presence of schema changes.

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex035/uploads/elm_lang/original/1X/50a05e53677a2c3b47776d7abd0f113eb50193a1.png) [@system](https://discourse.elm-lang.org/u/system)\
**Post date:** [October 5, 2023, 10:12am UTC](https://discourse.elm-lang.org/t/airsequel-0-6-teams-pro-plan-api-access-control-and-more/9327/5 "2023-10-05T10:12:00Z")

</div>

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.