Add a close() method to the PostgreSQLOnlineStore

Is your feature request related to a problem? Please describe.
When running the online store as a web app, I want to make sure that the connections made to the Postgres database using the PostgreSQLOnlineStore class are terminated gracefully.

Describe the solution you'd like
A close() method on the PostgreSQLOnlineStore which closes all open connections and connection pools.

Describe alternatives you've considered

Additional context

What's the point of adding this to PostgreSQLOnlineStore if it's not part of OnlineStore? How are you thinking of calling it?

@tokoko

What's the point of adding this to PostgreSQLOnlineStore if it's not part of OnlineStore? How are you thinking of calling it?

That is a valid point. It is possible as follows: feature_store._provider.online_store.close(). Where feature_store is an instance of the FeatureStore class. However, this is not ideal, given the fact that the provider object is private.

Do you think it would be an option to add a close() method on the OnlineStore class? This would also open the possibility for other online stores to implement a similar method.
We could do a similar approach as for the retrieve_online_documents function here. By not making it a mandatory function, but an optional one.

Let me know what you think! @tokoko

public/private issue can be remedied in some way, I suppose. I think my main concern here is that I don't fully understand what a close method on an abstract OnlineStore class should mean and how/when it could be used. The implementation details would naturally be left up to individual online stores, but what should be the result of closing an online store? Would it make online store unusable from that point on in that process so that subsequent calls may throw an exception? Or would it simply clean up resources held to save on utilization?

Also just an aside, what's the actual practical use case here? I couldn't really come up with an actual use case where I would need to clean up connections but for some reason keep the process running.

Would it make online store unusable from that point on in that process so that subsequent calls may throw an exception? Or would it simply clean up resources held to save on utilization?

This is debatable, but I believe the second option is preferable. In that case, all connections would be closed, but if the same object is used again, it would re-create the connections and continue to function.

I think the current implementation follows the second approach, but I would need to test or double-check to confirm.

Also just an aside, what's the actual practical use case here?

For us, it’s the following: We run different web applications that expose an ML model and require features during inference. For these features, we use Feast. These web apps maintain various "contexts," which are connections to different systems—one of which is a connection to the Feast feature store.

In our case, the web app might keep running, but the "app" object, and therefore all system connections, could be re-created. Without this close method, the connections to the feature store remain open, potentially resulting in an excessive number of connections and reaching the maximum connection limit, which is undesirable.

In our case, the web app might keep running, but the "app" object, and therefore all system connections, could be re-created. Without this close method, the connections to the feature store remain open, potentially resulting in an excessive number of connections and reaching the maximum connection limit, which is undesirable.

Isn't connection pool configuration a better solution here? With min_size set to 0 and a small enough max_idle, you should accomplish essentially the same outcome w/o changes to the API.

This is debatable, but I believe the second option is preferable. In that case, all connections would be closed, but if the same object is used again, it would re-create the connections and continue to function.

We should probably come up with a better name then if we go forward with this.

Isn't connection pool configuration a better solution here? With min_size set to 0 and a small enough max_idle, you should accomplish essentially the same outcome w/o changes to the API.

That is also a good idea, I didn't think of this before.

We should probably come up with a better name then if we go forward with this.

Do you have any ideas? ChatGPT came up with these

release_resources
reset_connections
terminate_connections
cleanup_connections

release_resources is probably the best one, but once again I'd much rather we don't make the change at all unless it's absolutely necessary. So probably best to try solving this with connection pools first. Let me know if I can help.

I'll close this issue and PR, since I agree with your train of thought.

Thanks a lot for your comments and thinking along! This really helps :)

I would like to reopen this issue as idle connections are not solely impacting the online store. I'm also experiencing the same problem with PostgreSQL (AWS RDS) being used as a registry store:

The current volume of idle connections is compelling us to upgrade our database class simply to accommodate a higher maximum connection limit.

Navigation Menu

Repository navigation

Add a close() method to the PostgreSQLOnlineStore #4401

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add a close() method to the PostgreSQLOnlineStore #4401

Description

Activity

tokoko commented on Aug 13, 2024

job-almekinders commented on Aug 15, 2024

tokoko commented on Aug 15, 2024

job-almekinders commented on Aug 20, 2024

tokoko commented on Aug 20, 2024

job-almekinders commented on Aug 21, 2024

tokoko commented on Aug 21, 2024

job-almekinders commented on Aug 22, 2024

fcas commented on May 29, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions